Comment configurer un service caché Tor sur un VPS anonyme

Faire tourner un service caché Tor depuis une connexion résidentielle française fonctionne tant que votre FAI ne renégocie pas l'offre, que le bail IPv4 ne tourne pas, et que personne muni d'une réquisition judiciaire ne sonne à votre porte. L'intérêt même d'une adresse en .onion est de découpler le service d'une identité réelle, et ce découplage s'effondre dès qu'on peut remonter le chemin réseau jusqu'à un nom inscrit sur une facture EDF ou Free. C'est précisément pour cette raison que les opérateurs qui visent la durabilité — nœuds Monero distants, serveurs BTCPay, ponts Matrix, miroirs de getmonero.org — louent presque toujours un serveur dédié virtuel chez un hébergeur acceptant le paiement sans vérification d'identité.

Ce guide déroule la chaîne complète pour 2026 : choisir un fournisseur VPS qui accepte le Monero ou les espèces non marquées, payer de façon anonyme, durcir une installation Debian 12 fraîche, et faire tourner un service oignon v3 qui survit aux reboots, aux mises à jour du noyau et au scan rDNS occasionnel. Les exemples partent du principe que vous voulez exposer un nœud Monero, mais la même recette s'applique à n'importe quel service TCP — Lightning, SSH, IRC, ou un site statique que vous préférez ne pas relier à votre état civil. Quand l'objectif est d'atteindre un service comme MoneroSwapper via un endpoint complètement isolé, c'est cette couche réseau qu'il faut maîtriser avant toute chose.

Pourquoi l'hébergement anonyme compte pour un service caché

Une adresse oignon Tor v3 dérive d'une clé publique ed25519. La garantie cryptographique est limpide : quiconque atteint le .onion passe par trois sauts de relais Tor, et le point de rendez-vous ne connaît jamais l'IP du serveur. Jusque-là, le protocole tient ses promesses. Ce que Tor ne peut pas masquer, en revanche, c'est le fait que vous avez payé 4,50 € par mois à Hetzner avec une Carte Bleue à votre nom. Au moment où une partie hostile corrèle des motifs d'uptime ou une fuite de configuration avec l'enregistrement de facturation, toute la propriété d'anonymat du service s'évapore.

Les modèles de menace qui justifient un VPS sans KYC sont concrets et se chevauchent :

• Pression judiciaire : Les hébergeurs grand public (Vultr, DigitalOcean, Hetzner, OVH, Scaleway) conservent les pièces d'identité et l'historique de paiement complet. Sous une réquisition judiciaire d'un juge d'instruction français, une injonction de production article 18 dans l'Union européenne, ou un mandat de l'autorité judiciaire dans le cadre de la loi Renseignement, ces dossiers sont remis avec un minimum de friction et sans publicité.
• Procédures civiles : Un référé pour atteinte à la vie privée, une plainte pour contrefaçon ou un litige de marque peut contraindre un hébergeur à identifier le client derrière une IP sans qu'aucune procédure pénale ne soit ouverte. La voie civile est plus rapide et moins coûteuse que la mise en examen.
• Empreinte côté réseau : Même quand un service caché est correctement configuré, des fuites au niveau applicatif (bannières serveur, source NTP, version du noyau dans les pages d'erreur) peuvent corréler le .onion avec une IP publique. Le paiement anonyme garantit que cette corrélation ne débouche pas sur un nom.
• Résilience opérationnelle : Les hébergeurs qui fonctionnent déjà sans KYC comprennent la surface de menace. Ils acceptent généralement de recevoir un signalement d'abus sans débrancher le VPS dans l'heure, parce qu'ils s'attendent à ce que leurs clients aient des raisons légitimes de chercher la confidentialité, plutôt que de traiter chaque plainte comme une vérité établie.

L'écosystème Monero en est l'exemple canonique. Les nœuds distants publics listés sur monero.fail ou dans la seed list par défaut de Cake Wallet tournent presque systématiquement comme services oignon v3 parce que leurs opérateurs veulent rendre service sans devenir des cibles. La même logique s'applique aux clients d'atomic swap, aux sidechains P2Pool et aux déploiements BTCPay côté marchand. Quand on a opéré l'un de ces services, on comprend vite pourquoi le couple VPS + oignon est la solution par défaut et non l'extrême paranoïaque.

Choisir un fournisseur VPS sans KYC en 2026

Après l'extension des règles FATF Travel Rule en 2024 et l'entrée en vigueur du CARF européen (Crypto-Asset Reporting Framework) le 1^er janvier 2026, la liste des fournisseurs acceptant un paiement véritablement anonyme s'est rétrécie, mais elle n'a pas disparu. Les hébergeurs européens qui ont survécu sont ceux qui se positionnent explicitement autour de la confidentialité, plutôt que de la traiter comme un argument marketing accessoire. Du côté offshore, les survivants sont ceux qui ont un historique documenté de refus des demandes spéculatives.

Trois constantes définissent un fournisseur utilisable sur ce marché :

1. Accepte le Monero (de préférence) ou le Bitcoin via des canaux compatibles avec un mixage propre, sans autre vérification que la confirmation d'une adresse e-mail valide capable de recevoir un lien à usage unique.
2. N'exige à aucune étape du parcours d'inscription un numéro de téléphone, une pièce d'identité officielle, un selfie, ou un handshake 3-D Secure.
3. Opère depuis une juridiction qui a une posture défendable sur la confidentialité — Islande, Suisse, Roumanie, Bulgarie, ou certaines zones offshore — plutôt que depuis un espace gris du droit américain.

Le tableau ci-dessous résume les fournisseurs les plus cités par les opérateurs Monero à la fin 2025, avec leur tarif d'entrée de gamme typique et les compromis principaux. Les prix fluctuent avec le taux XMR/EUR ; voyez-les comme des ordres de grandeur.

Fournisseur	Tarif d'entrée / mois	Avantages	Inconvénients
Njalla (SE/NL)	~15 €	Historique solide en matière de confidentialité, accepte le Monero directement, dispose de son propre ASN et d'un service de domaine en fiducie.	Tarif plus élevé, flotte limitée, liste d'attente VPS récurrente.
1984 Hosting (IS)	~10 €	Juridiction islandaise, énergie géothermique, Monero accepté via passerelle tierce.	Stock IPv4 limité, une seule région de datacenter.
BitLaunch (multi)	~5 $	Revend DigitalOcean, Vultr et Linode derrière une façade crypto, déploiements rapides, facturation à l'heure.	Le fournisseur en amont conserve les logs réseau ; pas blindé contre une réquisition adressée à la maison mère.
Cockbox (US)	~15 $	Opérateur orienté liberté d'expression, Monero accepté, politique no-logs publique.	Juridiction américaine, structure d'une seule personne, pas de SLA.
BuyVM / Frantech (LU/CA)	~3,50 $	Option pérenne la moins chère, accepte le crypto, bande passante non comptée généreuse sur la plupart des plans.	Communication moins axée privacy ; l'hygiène de paiement est à votre charge.
Privex (multi)	~5 €	Hébergeur Monero-friendly de longue date, présence en Islande et en Suède, propose des offres IPv6-only.	Stock fluctuant, matériel ancien sur l'entrée de gamme.

Payez en Monero chaque fois que l'option existe. Les paiements Bitcoin, même routés via CoinJoin ou un swap non-KYC, laissent un graphe d'UTXO traçable que les analyses de chaîne futures pourront condenser. Le RingCT de Monero, ses Bulletproofs+ et la construction d'adresses furtives rendent la désanonymisation côté paiement effectivement impossible avec les techniques publiées à ce jour. Si un fournisseur n'accepte que le Bitcoin, utilisez MoneroSwapper ou un swap équivalent sans compte pour convertir XMR en BTC au dernier moment, envoyez directement à l'adresse de paiement depuis un portefeuille neuf, et ne réutilisez jamais le portefeuille source pour quoi que ce soit d'autre.

Hygiène de l'e-mail et de l'inscription

Utilisez un e-mail neuf par fournisseur — boîtes jetables comme cock.li, danwin1210.de, ou un catch-all auto-hébergé sur un domaine séparé. Ne réutilisez jamais un nom d'utilisateur, un mot de passe, ni une empreinte de clé SSH qui existerait dans un autre contexte. L'IP d'inscription doit déjà être sous Tor ou derrière un VPN qui n'est pas payé avec la même identité qu'un autre service que vous opérez. Traitez chaque champ du formulaire comme une divulgation permanente : tout ce que vous tapez dans l'inscription constitue la surface d'identification la plus défavorable pour toute la durée de vie du VPS, et cette durée se compte en années.

Pas à pas : déployer un service oignon Tor v3

La procédure ci-dessous part d'un VPS Debian 12 (Bookworm) fraîchement provisionné, avec une seule IPv4 publique, un accès SSH root, et la location déjà payée en Monero. Les étapes sont rédigées pour être copiables, mais lisez chacune d'entre elles avant de l'exécuter — les valeurs par défaut changent d'une version à l'autre, et un copier-coller distrait peut vous enfermer hors de la machine.

1. Durcissement initial. Connectez-vous en SSH en tant que root, créez un utilisateur non-root avec sudo, désactivez la connexion root et l'authentification par mot de passe dans /etc/ssh/sshd_config, redémarrez sshd, et activez ufw avec deny par défaut en entrée. N'ouvrez que SSH (de préférence sur un port non standard) jusqu'à ce que Tor soit installé et vérifié.
2. Mises à jour système et paquets de base. Lancez apt update && apt full-upgrade -y, puis installez tor, nyx, ufw, fail2ban, unattended-upgrades et apt-listbugs. Activez les mises à jour de sécurité automatiques via dpkg-reconfigure -plow unattended-upgrades et confirmez avec systemctl status unattended-upgrades.
3. Installer le dépôt officiel Tor. Le paquet Tor de Debian est souvent en retard de plusieurs semaines. Ajoutez le dépôt du Tor Project à /etc/apt/sources.list.d/tor.list, importez la clé de signature, et réinstallez tor et tor-geoipdb depuis l'amont. Vérifiez avec tor --version — attendez-vous à 0.4.8.x ou plus récent tout au long de 2026.
4. Configurer le service caché. Éditez /etc/tor/torrc : ajoutez HiddenServiceDir /var/lib/tor/monero-node/, puis HiddenServicePort 18089 127.0.0.1:18089 pour un nœud Monero distant public, et enfin HiddenServiceVersion 3. Pour des services autres que Monero, mappez le port que votre application écoute en local vers le port que vous voulez exposer sur l'oignon.
5. Démarrer Tor et lire l'adresse oignon. Lancez systemctl restart tor@default, attendez que nyx affiche un bootstrap réussi à 100 %, puis cat /var/lib/tor/monero-node/hostname. L'adresse ed25519 de 56 caractères terminée par .onion est l'identité de votre service. Sauvegardez le contenu du répertoire — en particulier hs_ed25519_secret_key — sur un support hors ligne chiffré, parce que le perdre revient à perdre l'adresse pour toujours.
6. Lier l'application à localhost uniquement. Modifiez la configuration de votre service pour qu'il écoute sur 127.0.0.1 plutôt que sur 0.0.0.0. Pour un démon Monero, mettez rpc-bind-ip=127.0.0.1 dans monerod.conf et passez le flag --restricted-rpc pour refuser les opérations de portefeuille sur l'endpoint public. Redémarrez l'application et vérifiez avec ss -tlnp que rien n'est attaché à l'interface publique.
7. Vérifier depuis l'extérieur. Depuis une machine séparée sous Tor Browser, naviguez vers l'adresse .onion. L'application doit répondre exactement comme elle le ferait en clearnet, sans qu'aucune fuite ne révèle l'IP sous-jacente dans les en-têtes ou les pages d'erreur. Utilisez curl --socks5-hostname 127.0.0.1:9050 http://votreservice.onion/ depuis n'importe quel poste Tor-enabled pour des vérifications scriptées.
8. Optionnel : générer un oignon de vanité. Des outils comme mkp224o font du brute-force de paires de clés ed25519 pour un préfixe donné. Un préfixe de 6 caractères demande quelques minutes sur un CPU récent ; 8 caractères, quelques heures ; 10 caractères, plusieurs jours sur GPU. Évitez les préfixes qui reproduisent votre nom légal, votre pseudo de projet, ou toute autre chaîne reliable — cela ruine tout l'intérêt de l'exercice.

Un service oignon n'est anonyme qu'à hauteur de sa fuite applicative la plus faible. Un nœud Monero qui imprime son hostname dans les messages d'erreur, ou un serveur web qui envoie un en-tête Server contenant le rDNS basé sur l'IP sous-jacente, compromet le déploiement quelle que soit la rigueur de la configuration Tor.

Durcissement, supervision et discipline opérationnelle

Le démon Tor n'est qu'un maillon. Le reste du système doit s'aligner sur son modèle de menace, sinon il devient le maillon faible. Désactivez complètement le swap avec swapoff -a et retirez l'entrée swap de /etc/fstab, pour que le matériel cryptographique ed25519 ne soit jamais paginé sur disque. Activez kernel.kptr_restrict=2, kernel.dmesg_restrict=1 et l'ensemble des sysctls de durcissement noyau livrés dans linux-hardening ou tirés de la référence sysctl de Whonix. Des profils AppArmor pour Tor et votre application ajoutent une couche supplémentaire pour un coût de configuration modeste.

Configurez nftables ou ufw pour rejeter tout trafic entrant à l'exception de SSH — et idéalement uniquement depuis vos IP d'administration, si vous en avez de stables. Sinon, comptez sur une authentification par clé robuste et un rate-limiting via fail2ban. En sortie, n'autorisez que ce dont Tor a besoin : TCP 443 et 9001/9030 pour le trafic de relais si la machine fait aussi office de relais Tor, et forcez la résolution DNS via le port SOCKS de Tor pour toute application qui en a besoin. Ne laissez jamais une application parler directement au résolveur DNS clearnet de l'hébergeur — ce chemin laisse silencieusement fuiter l'existence de votre application dans les logs du fournisseur.

Supervisez localement avec nyx et exportez les métriques Prometheus via le service oignon lui-même si vous avez besoin de graphes à distance. Évitez de pousser des logs ou des métriques vers n'importe quel SaaS tiers — c'est un vecteur de désanonymisation manuel d'école. La rotation des logs doit être agressive : logrotate en quotidien avec maxage 7, et journalctl --vacuum-time=7d dans une tâche cron hebdomadaire. Moins il y a de données historiques sur le disque, moins il y en a à saisir pour un acteur hostile, et moins il y aura à expliquer après coup.

Les sauvegardes méritent leur propre discipline. Le fichier hs_ed25519_secret_key est le seul état que vous ne pouvez pas régénérer. Chiffrez-le avec age ou GPG en utilisant une passphrase robuste, stockez-le sur au moins deux supports hors ligne (clés USB plus un base64 imprimé papier dans une enveloppe scellée), et gardez une copie géographiquement séparée de votre lieu principal. Pour le reste du système, reconstruisez à partir d'un outil de gestion de configuration (Ansible, NixOS, ou scripts shell dans un dépôt privé) plutôt que de sauvegarder l'image disque entière — le système doit être éphémère, seul le secret doit être stable.

Cadre légal français : ce qu'il faut savoir avant de déployer

Faire tourner un service caché Tor depuis une juridiction extérieure ne vous exempte pas du droit français qui s'applique à votre activité d'utilisateur sur le territoire. La LCEN (loi pour la confiance dans l'économie numérique) impose des obligations de conservation aux hébergeurs établis en France, raison pour laquelle on cherche systématiquement à louer ailleurs. La loi Renseignement de 2015 et ses mises à jour autorisent les services à demander des données de connexion auprès des opérateurs sous contrôle de la CNCTR. Pour le contenu hébergé hors UE, ces leviers perdent en efficacité, ce qui est précisément l'effet recherché.

Côté paiement, l'ACPR et Tracfin s'intéressent aux flux crypto à partir des plateformes enregistrées comme PSAN. Un achat de Monero via une plateforme française enregistrée laisse une trace qui peut être reliée à votre VPS si vous payez directement avec ces fonds. Privilégiez un swap atomique ou un échange non-custodial entre votre achat initial et l'adresse de paiement de l'hébergeur, et idéalement faites « reposer » les fonds dans un portefeuille intermédiaire pendant quelques jours pour casser toute corrélation temporelle évidente. La CNIL et le RGPD encadrent par ailleurs ce que vous pouvez collecter sur les utilisateurs de votre service caché ; même en .onion, exposer un formulaire qui stocke des données personnelles vous place sous le régime du règlement européen si vous êtes résident français.

FAQ

Puis-je faire tourner un service caché Tor depuis chez moi plutôt qu'un VPS ?

Techniquement oui — Tor se moque de l'endroit où vit le serveur. En pratique, les connexions résidentielles introduisent un risque d'uptime (coupures EDF, renégociation d'abonnement Free ou Orange, rotation d'IP dynamique cassant les relais de garde de longue durée), et toute fuite qui expose l'IP publique fait s'effondrer l'anonymat jusqu'à votre identité de facturation chez le FAI. Un VPS sans KYC isole le service de votre empreinte réelle pour un coût modeste — 5 à 15 € par mois — et la plupart des opérateurs expérimentés considèrent ce compromis comme évident.

Payer en Monero me protège-t-il vraiment vis-à-vis de l'hébergeur ?

Côté paiement, oui. Le RingCT de Monero, les signatures de cercle, les adresses furtives et le relais transactionnel Dandelion++ cassent le lien entre votre portefeuille et l'adresse de dépôt à laquelle vous payez. Le fournisseur VPS voit arriver un paiement sans expéditeur en clair. Ce que l'hygiène de paiement ne peut pas réparer, c'est le reste du processus d'inscription : un e-mail utilisé ailleurs, un nom d'utilisateur tiré d'un forum public, ou une empreinte de clé SSH partagée avec un compte non anonyme. Voyez l'anonymat comme une chaîne — le Monero en est un maillon, pas la totalité.

Combien de temps une adresse oignon v3 reste-t-elle valable ?

Indéfiniment, tant que vous gardez le fichier hs_ed25519_secret_key en sécurité. L'adresse dérive de manière déterministe de cette clé. Vous pouvez copier le répertoire sur un nouveau VPS, redémarrer Tor, et la même adresse .onion résoudra vers le nouveau serveur en quelques minutes. C'est le socle de la résilience opérationnelle : quand un VPS devient suspect ou indisponible, vous migrez la clé, pas l'adresse, et les clients se reconnectent sans aucun changement de leur côté.

Faut-il faire tourner son propre nœud Monero, ou peut-on utiliser un nœud public via Tor ?

Les deux sont légitimes. Les nœuds oignon publics (listés sur monero.fail) sont pratiques et ne demandent aucune infrastructure, mais ils voient vos broadcasts de transactions et vos requêtes. Faire tourner votre propre nœud derrière votre propre service caché coûte environ 200 Go de disque plus la facture VPS, mais cela supprime entièrement l'exigence de confiance. Pour des flux à forte valeur — y compris la conversion de fonds via MoneroSwapper sans laisser de métadonnées corrélables à un endpoint tiers — le nœud auto-hébergé est la posture matériellement plus solide.

Que se passe-t-il si ma clé privée de service caché est saisie ?

Quiconque détient le fichier hs_ed25519_secret_key peut servir du trafic sur votre adresse .onion depuis n'importe quelle infrastructure qu'il contrôle, et la substitution est indiscernable pour les clients. Les sauvegardes doivent donc être chiffrées au repos avec une passphrase que vous seul connaissez — le chiffrement intégral du disque sur le VPS seul ne suffit pas, car le système en fonctionnement garde la clé en mémoire. Si une saisie est imminente, basculez immédiatement vers une nouvelle adresse oignon et annoncez le changement via un canal hors bande préalablement signé que vos clients reconnaissent déjà.

Conclusion

Mettre en place un service caché Tor sur un VPS anonyme n'est pas un produit qu'on achète d'un seul geste ; c'est une suite de décisions sur la juridiction, l'hygiène de paiement, le durcissement système et la gestion de clés. Chaque étape ferme une surface d'identification et en laisse d'autres visibles. L'intérêt de toutes les enchaîner est qu'aucun échec unique — un audit chez le fournisseur, une bannière mal configurée, une ligne de log oubliée — ne fait s'effondrer toute la pile. Pour les opérateurs Monero et pour quiconque a besoin d'infrastructure durable sans KYC, la recette ci-dessus constitue la ligne de base de travail. Quand le service que vous atteignez de l'autre côté est quelque chose comme l'endpoint oignon de MoneroSwapper, les mêmes standards s'appliquent côté client : maîtrisez le chemin de bout en bout, ou acceptez le fait que vous n'avez pas, en réalité, de confidentialité.