Come configurare un servizio nascosto Tor su VPS anonimo

Gestire un servizio nascosto Tor da una connessione residenziale funziona benissimo, almeno finché il provider non rinegozia il contratto, l'IPv4 dinamico non cambia all'improvviso, oppure qualcuno con un decreto della Procura non si presenta al portone di casa. Il senso stesso di un indirizzo .onion è scollegare il servizio da un'identità anagrafica, e questo disaccoppiamento crolla nel momento in cui il percorso di rete sottostante può essere ricondotto a un nome stampato su una bolletta. È per questo che gli operatori che ragionano in termini di durata pluriennale — nodi remoti Monero, server BTCPay, bridge Matrix, mirror di getmonero.org — affittano quasi sempre un VPS dedicato presso un host che accetta pagamenti senza verifica dell'identità.

Questa guida copre l'intera filiera operativa per il 2026: come scegliere un provider VPS che accetta Monero o contanti in busta, come pagare in modo anonimo, come irrobustire un'installazione fresca di Debian 12 e come portare online un servizio onion v3 che sopravviva a riavvii, aggiornamenti del kernel e scansioni rDNS occasionali. Gli esempi presuppongono che l'obiettivo sia esporre un nodo Monero, ma la stessa ricetta vale per qualunque servizio TCP — Lightning, SSH, IRC, o un sito statico che preferireste non collegare al vostro nome legale. Quando l'obiettivo è raggiungere un servizio come MoneroSwapper attraverso un endpoint completamente isolato, questo strato di rete è la parte che deve essere a posto prima di qualunque altra cosa.

Perché l'hosting anonimo conta per i servizi nascosti

Un indirizzo onion v3 deriva da una chiave pubblica ed25519. La garanzia crittografica è lineare: chiunque raggiunga l'.onion si connette attraverso tre salti di relay Tor, e il rendezvous point non viene mai a sapere l'IP del server. Fin qui tutto è solido. Quello che Tor non può fare è nascondere il fatto che avete pagato Hetzner 4,50 € al mese con una Visa intestata al vostro nome. Nel momento in cui una controparte ostile correla pattern di uptime o una fuga di configurazione con il record di fatturazione, l'intera proprietà di anonimato del servizio evapora.

I modelli di minaccia che giustificano un VPS senza KYC sono concreti e si sovrappongono:

• Pressione tramite ordine giudiziario: i provider mainstream (Vultr, DigitalOcean, Hetzner, OVH, Aruba) conservano dati KYC e cronologia completa dei pagamenti. Sotto un decreto di esibizione della Procura della Repubblica, un ordine di produzione europeo ai sensi del Regolamento UE 2023/1543, o un'analoga richiesta del Regno Unito ai sensi dell'Investigatory Powers Act, quei dati vengono consegnati con attrito minimo e senza notifica pubblica all'interessato.
• Acquisizione probatoria in sede civile: una causa per diffamazione, una contestazione sul diritto d'autore o una controversia marchiale possono costringere un provider a identificare il cliente dietro un IP senza alcun procedimento penale di mezzo. Il rito civile è più rapido ed economico dell'indagine preliminare, e l'ordinanza di esibizione ex art. 210 c.p.c. è uno strumento ben rodato.
• Fingerprinting lato rete: anche quando un servizio nascosto è configurato correttamente, le fughe a livello applicativo (banner del server, sorgente NTP, versione del kernel nelle pagine di errore) possono correlare l'.onion con un IP pubblico. Il pagamento anonimo garantisce che quella correlazione non riconduca a un nome anagrafico.
• Resilienza operativa: i provider che operano abitualmente senza KYC conoscono il proprio terreno. Di norma sono disposti a ricevere una segnalazione di abuso senza fare immediatamente terra bruciata del VPS, perché si aspettano che i loro clienti abbiano ragioni legittime di privacy, invece di trattare ogni reclamo come verità acquisita.

L'ecosistema Monero è l'esempio canonico. I nodi remoti pubblici listati su monero.fail o nella lista predefinita di Cake Wallet girano regolarmente come servizi onion v3, perché gli operatori vogliono fornire il servizio senza diventare un bersaglio. La stessa logica vale per i client di atomic swap, per le sidechain P2Pool e per i deployment BTCPay lato esercente. Una volta che avete gestito anche solo uno di questi sistemi, si capisce in fretta perché la combinazione VPS-più-onion sia diventata l'impostazione predefinita e non un estremismo paranoico.

Come scegliere un provider VPS senza KYC nel 2026

Dopo l'estensione del Travel Rule del GAFI nel 2024 e l'entrata in vigore del CARF (Crypto-Asset Reporting Framework) dell'Unione Europea il 1° gennaio 2026, la lista dei provider che accettano pagamenti realmente anonimi si è ridotta ma non è scomparsa. Gli hoster europei sopravvissuti sono quelli che si sono esplicitamente posizionati intorno alla privacy invece di trattarla come un dettaglio di marketing, e i provider offshore sopravvissuti sono quelli con un curriculum documentato di rifiuti opposti a richieste esplorative.

Tre costanti definiscono un provider utilizzabile in questo mercato:

1. Accetta Monero (preferibile) o Bitcoin attraverso canali compatibili con il mixing, senza verifica via email oltre a un indirizzo funzionante che riceva un link monouso.
2. Non richiede un numero di telefono, il caricamento di un documento d'identità, un selfie o una conferma 3-D Secure della carta in nessun punto del flusso di registrazione.
3. Opera da una giurisdizione con una postura difendibile verso la privacy — Islanda, Svizzera, Romania, Bulgaria o specifiche zone offshore — invece di trovarsi in un caso limite del Quinto Emendamento negli Stati Uniti.

La tabella seguente sintetizza i provider più citati dagli operatori Monero a fine 2025, con i prezzi della fascia base e i compromessi principali. I prezzi oscillano con il cambio XMR/EUR; vanno trattati come stime di massima.

Provider	Prezzo base / mese	Punti di forza	Limiti
Njalla (SE/NL)	~15 €	Solido curriculum sulla privacy, accetta Monero in diretta, gestisce un proprio ASN con registrazione dominio custodita.	Fascia di prezzo più alta, parco macchine ridotto, occasionale lista d'attesa.
1984 Hosting (IS)	~10 €	Giurisdizione islandese, alimentazione geotermica, Monero accettato via gateway di terze parti.	Scorta IPv4 limitata, una sola regione datacenter.
BitLaunch (multi)	~5 $	Rivende DigitalOcean, Vultr e Linode dietro un front-end crypto, deploy molto rapidi, fatturazione oraria.	Il provider sottostante conserva comunque i log di rete; non a prova di richiesta a monte.
Cockbox (US)	~15 $	Operatore orientato alla libertà di parola, Monero accettato, policy no-logs pubblica.	Giurisdizione USA, struttura piccola gestita da una persona, nessuno SLA.
BuyVM / Frantech (LU/CA)	~3,50 $	Opzione continuativa più economica, accetta crypto, banda illimitata generosa sulla maggior parte dei piani.	Branding meno orientato alla privacy; l'igiene del pagamento ricade sull'utente.
Privex (multi)	~5 €	Host storicamente amico di Monero, presenze in Islanda e Svezia, fasce solo IPv6 disponibili.	Stock variabile, hardware datato nella fascia più economica.

Pagate in Monero ogni volta che l'opzione esiste. I pagamenti in Bitcoin, anche se passati attraverso CoinJoin o uno scambio non-KYC, lasciano un grafo di UTXO tracciabile che l'analisi catena del futuro potrebbe ricomporre. La costruzione di Monero basata su RingCT, Bulletproofs+ e stealth address rende la deanonimizzazione lato pagamento sostanzialmente impossibile con le tecniche pubblicate ad oggi. Se un provider accetta soltanto Bitcoin, usate MoneroSwapper o uno scambio equivalente senza account per convertire XMR in BTC all'ultimo momento utile, inviate direttamente all'indirizzo di pagamento da un portafoglio appena creato, e non riutilizzate mai più quel portafoglio sorgente per nient'altro.

Igiene di email e registrazione

Usate un indirizzo email nuovo per ogni provider — caselle usa-e-getta come cock.li, danwin1210.de, oppure un catch-all auto-ospitato su un dominio separato. Non riutilizzate mai uno username, una password o un'impronta di chiave SSH che esista in qualunque altro contesto. L'IP da cui vi registrate dovrebbe già trovarsi su Tor o su una VPN che non sia pagata con la stessa identità di nient'altro che gestite. Trattate ogni campo del modulo come una rivelazione permanente: qualunque cosa digitate al momento della registrazione costituisce la peggior superficie di identificazione per l'intero ciclo di vita del VPS, e quel ciclo di vita può estendersi su anni.

Passo per passo: deploy di un servizio onion v3

La procedura che segue presuppone un VPS Debian 12 (Bookworm) fresco, con un singolo IPv4 pubblico, accesso SSH come root e il canone già pagato in Monero. I passaggi sono pensati per essere copia-e-incolla, ma leggete ciascuno prima di eseguirlo — i valori predefiniti cambiano tra una release e l'altra, e un incollaggio fatto distrattamente vi può chiudere fuori dalla macchina.

1. Irrobustimento iniziale. Entrate in SSH come root, create un utente non root con sudo, disabilitate il login di root e l'autenticazione a password in /etc/ssh/sshd_config, riavviate sshd e abilitate ufw con default-deny in ingresso. Aprite solo SSH (preferibilmente su una porta non standard) finché Tor non è installato e verificato.
2. Aggiornamenti di sistema e pacchetti di base. Eseguite apt update && apt full-upgrade -y, poi installate tor, nyx, ufw, fail2ban, unattended-upgrades e apt-listbugs. Abilitate gli aggiornamenti di sicurezza automatici con dpkg-reconfigure -plow unattended-upgrades e verificate con systemctl status unattended-upgrades.
3. Installate il repository ufficiale di Tor. La versione di Tor distribuita da Debian è spesso indietro di settimane. Aggiungete il repository del Tor Project in /etc/apt/sources.list.d/tor.list, importate la chiave di firma e reinstallate tor e tor-geoipdb dalla fonte ufficiale. Verificate con tor --version — durante tutto il 2026 ci si aspetta 0.4.8.x o più recente.
4. Configurate il servizio nascosto. Modificate /etc/tor/torrc: aggiungete HiddenServiceDir /var/lib/tor/monero-node/, poi HiddenServicePort 18089 127.0.0.1:18089 per un nodo remoto Monero pubblico, e infine HiddenServiceVersion 3. Per servizi non Monero, mappate la porta su cui ascolta localmente l'applicazione sulla porta che volete esporre sull'onion.
5. Avviate Tor e leggete l'indirizzo onion. Eseguite systemctl restart tor@default, attendete che nyx mostri un bootstrap completato al 100%, poi cat /var/lib/tor/monero-node/hostname. L'indirizzo ed25519 di 56 caratteri che termina con .onion è l'identità del servizio. Fate un backup del contenuto della directory — in particolare hs_ed25519_secret_key — su un supporto offline cifrato, perché perderlo significa perdere l'indirizzo per sempre.
6. Vincolate l'applicazione al solo localhost. Modificate la configurazione del servizio in modo che ascolti su 127.0.0.1 invece di 0.0.0.0. Per un demone Monero, impostate rpc-bind-ip=127.0.0.1 in monerod.conf e passate il flag --restricted-rpc per rifiutare operazioni di portafoglio sull'endpoint pubblico. Riavviate l'applicazione e verificate con ss -tlnp che nulla sia in ascolto sull'interfaccia pubblica.
7. Verificate dall'esterno. Da una macchina distinta su cui gira Tor Browser, navigate verso l'indirizzo .onion. L'applicazione deve rispondere esattamente come farebbe in chiaro, senza alcuna fuga dell'IP sottostante negli header o nelle pagine di errore. Usate curl --socks5-hostname 127.0.0.1:9050 http://vostroservizio.onion/ da qualunque host con Tor attivo per controlli automatizzati.
8. Opzionale: generate un onion vanity. Strumenti come mkp224o fanno brute-force sulle coppie di chiavi ed25519 per cercare un prefisso desiderato. Un prefisso di 6 caratteri richiede minuti su una CPU moderna; 8 caratteri richiedono ore; 10 caratteri richiedono giorni su una GPU. Evitate prefissi che coincidono con il vostro nome legale, l'alias di un progetto o qualunque altra stringa collegabile — vanificate l'intero esercizio.

Un servizio onion è anonimo quanto la più debole delle sue fughe a livello applicativo. Un nodo Monero che stampa il proprio hostname nei messaggi di errore, o un webserver che invia un header Server con il reverse DNS basato sull'IP sottostante, comprometteranno il deployment a prescindere da quanta attenzione abbiate messo nella configurazione di Tor.

Hardening, monitoraggio e disciplina operativa

Il demone Tor è un solo componente. Il resto del sistema deve essere all'altezza del suo modello di minaccia, altrimenti diventa l'anello debole della catena. Disabilitate completamente lo swap con swapoff -a e rimuovete la voce di swap da /etc/fstab, in modo che il materiale segreto ed25519 non venga mai paginato su disco. Abilitate kernel.kptr_restrict=2, kernel.dmesg_restrict=1 e il resto degli sysctl di irrobustimento del kernel raccolti in linux-hardening o ripresi dal riferimento sysctl di Whonix. I profili AppArmor per Tor e per la vostra applicazione aggiungono un ulteriore strato a costi di configurazione contenuti.

Configurate nftables o ufw in modo da scartare tutto il traffico in ingresso tranne SSH — e idealmente solo dai vostri IP di gestione, se ne avete di stabili. In alternativa affidatevi a un'autenticazione a chiave forte e al rate-limiting con fail2ban. In uscita, permettete solo ciò di cui Tor ha bisogno: TCP 443 e 9001/9030 per il traffico di relay se la macchina opera anche come relay Tor, e forzate il DNS attraverso la porta SOCKS di Tor per qualunque applicazione che richieda la risoluzione dei nomi. Non lasciate mai che un'applicazione parli direttamente al risolutore DNS in chiaro del provider VPS — quel percorso fa trapelare silenziosamente l'esistenza della vostra applicazione nei log del provider.

Monitorate localmente con nyx e fate uscire le metriche Prometheus attraverso il servizio onion stesso, se vi serve un grafico remoto. Evitate di spingere log o metriche verso qualunque SaaS di terze parti — è un vettore di deanonimizzazione da manuale. La rotazione dei log dev'essere aggressiva: logrotate quotidiano con maxage 7, e journalctl --vacuum-time=7d in un cron job settimanale. Meno dati storici giacciono sul disco, meno cose un attore ostile può sequestrare e meno cose dovrete spiegare a posteriori.

I backup meritano una disciplina a parte. Il file hs_ed25519_secret_key è l'unico pezzo di stato che non potete rigenerare. Cifratelo con age o GPG usando una passphrase robusta, conservatelo su almeno due supporti offline (chiavette USB più una stampa cartacea in base64 in una busta sigillata) e tenete una copia geograficamente separata dalla vostra posizione principale. Per il resto del sistema, ricostruite a partire dal configuration management (Ansible, NixOS o shell script in un repository privato) invece di fare il backup dell'intera immagine disco — il sistema dev'essere effimero e solo il segreto dev'essere stabile.

Aspetti legali rilevanti per operatori italiani

Chi opera da residente in Italia farebbe bene a tenere a mente alcuni nodi specifici. Il Codice in materia di protezione dei dati personali (D.Lgs. 196/2003 come modificato dal D.Lgs. 101/2018) e il GDPR si applicano all'operatore del servizio in quanto titolare del trattamento, anche quando il servizio è ospitato all'estero, se i visitatori sono identificabili o se vengono raccolti dati personali. Un nodo Monero remoto che non logga indirizzi IP è generalmente fuori dal perimetro del GDPR, ma un'istanza Matrix o BTCPay sullo stesso onion può ricadervi appieno. Il Garante per la protezione dei dati personali è competente in caso di reclamo, e una sanzione amministrativa può arrivare a percentuali significative del fatturato anche per persone fisiche che svolgono attività che il Garante qualifica come economiche.

Sul fronte penale, la Procura della Repubblica può ottenere un decreto di acquisizione dati di traffico telematico ai sensi del D.Lgs. 109/2008 e successive modifiche, con periodi di conservazione che dopo la riforma sono tornati a essere significativi per i reati gravi. Il punto è semplice: se la connessione di pagamento o il percorso di registrazione passa per un'identità italiana, quella catena è ricostruibile. Spostare il pagamento su Monero e la registrazione su Tor non è solo prudenza tecnica, è anche il modo per non costringere voi stessi a dimostrare la legittimità di un'attività che era e resta perfettamente legittima — gestire un nodo Monero, un mirror getmonero.org o un servizio Matrix.

FAQ

Posso gestire un servizio nascosto Tor da casa invece che da un VPS?

Tecnicamente sì — a Tor non interessa dove si trovi il server. Sul piano pratico le connessioni residenziali introducono rischi di uptime (interruzioni elettriche, rinegoziazione del contratto col provider, rotazione dell'IP dinamico che rompe i guard relay di lunga durata), e qualunque fuga che esponga l'IP pubblico fa collassare l'anonimato fino alla vostra identità di fatturazione presso il provider di accesso. Un VPS no-KYC isola il servizio dalla vostra impronta anagrafica a un costo modesto — dai 5 ai 15 € al mese — e la maggior parte degli operatori esperti considera questo compromesso evidente.

Pagare in Monero mi nasconde davvero al provider VPS?

Dal lato pagamento, sì. RingCT, le ring signature, gli stealth address e il rilancio Dandelion++ delle transazioni Monero spezzano il legame tra il vostro portafoglio e l'indirizzo di deposito sul quale state pagando. Il provider VPS vede un pagamento in arrivo senza mittente in chiaro. Quello che l'igiene del pagamento non può sistemare è il resto del processo di registrazione: un'email usata altrove, uno username ripreso da un forum pubblico o un'impronta di chiave SSH condivisa con un account non anonimo. Trattate l'anonimato come una catena — Monero è un solo anello, non l'intera struttura.

Quanto dura un indirizzo onion v3?

A tempo indefinito, fintanto che mantenete al sicuro il file hs_ed25519_secret_key. L'indirizzo viene derivato in modo deterministico da quella chiave. Potete copiare la directory su un nuovo VPS, riavviare Tor, e lo stesso .onion risolve verso il nuovo server in pochi minuti. Questa è la base della resilienza operativa: quando un VPS diventa inaffidabile o non disponibile, migrate la chiave, non l'indirizzo, e i client si riconnettono senza dover cambiare nulla dal lato loro.

Devo gestire un mio nodo Monero, o posso usarne uno pubblico via Tor?

Entrambe le strade sono legittime. I nodi onion pubblici (elencati su monero.fail) sono comodi e non richiedono infrastruttura, ma vedono i vostri broadcast di transazione e le vostre interrogazioni. Gestire un nodo proprio dietro un proprio servizio nascosto costa indicativamente 200 GB di disco più il canone del VPS, ma elimina del tutto il requisito di fiducia. Per flussi di valore elevato — incluso convertire fondi tramite MoneroSwapper senza lasciare metadati correlabili presso alcun endpoint di terze parti — il nodo auto-ospitato è la postura materialmente più solida.

Cosa succede se la chiave privata del mio servizio nascosto viene sequestrata?

Chiunque sia in possesso del file hs_ed25519_secret_key può servire traffico sul vostro .onion da qualunque infrastruttura controlli, e la sostituzione è indistinguibile per i client. I backup devono quindi essere cifrati a riposo con una passphrase che solo voi conoscete — la cifratura full-disk sul solo VPS non è sufficiente, perché il sistema in esecuzione tiene la chiave in memoria. Se un sequestro è imminente, ruotate immediatamente verso un nuovo indirizzo onion e annunciate il cambio attraverso un canale fuori banda firmato in precedenza, su cui i vostri client già ripongono fiducia.

Il Garante per la protezione dei dati personali può intervenire sul mio servizio onion?

Dipende da che cosa serve il servizio. Se trattate dati personali di utenti identificabili — anche solo via cookie di sessione o handle di chat — siete titolari del trattamento ai sensi del GDPR e del Codice privacy italiano, e il Garante è competente. Se invece il servizio è un nodo crypto puramente protocollare senza raccolta di dati identificativi, il perimetro del GDPR non si applica nei fatti. La sostanza tecnica del servizio è quella che determina la qualificazione giuridica, non l'etichetta che gli date.

Conclusione

Configurare un servizio nascosto Tor su un VPS anonimo non è l'acquisto di un singolo prodotto; è una sequenza di decisioni su giurisdizione, igiene del pagamento, irrobustimento del sistema e gestione delle chiavi. Ogni passaggio chiude una superficie di identificazione e lascia il resto visibile. Il senso di farli tutti insieme è che nessun singolo cedimento — un audit del provider, un banner mal configurato, una riga di log che trapela — fa collassare l'intera pila. Per gli operatori Monero e per chiunque altro abbia bisogno di un'infrastruttura durevole e senza KYC, la ricetta sopra è la base operativa di lavoro. Quando il servizio che raggiungete dall'altra parte è qualcosa come l'endpoint onion di MoneroSwapper, gli stessi standard si applicano anche dal lato del client: possedete il percorso end-to-end, oppure accettate che, in concreto, di privacy non ne avete.