
Ospiti in autonomia un hidden service Tor v3.
Venti minuti per il suo .onion personale.
Cinque passaggi dal provisioning di un VPS a un indirizzo onion v3 di 56 caratteri attivo raggiungibile solo attraverso la rete Tor. Testato su Debian 12 con il repository ufficiale del Tor Project.
- 01
Provisioning
Un VPS nordico
- 02
Installare
Pacchetto Tor ufficiale
- 03
Configura
Due righe in torrc
- 04
Ottenere indirizzo
cat .../hostname
- 05
Hardening
Permessi + isolamento
Qualsiasi bastione nordico va bene. Tor si occupa della geografia.
A differenza di un sito clearnet, un hidden service non si preoccupa molto di quale bastion fisico lo ospita — i client la raggiungono attraverso tre relay Tor, quindi la latenza verso il bastion non influisce molto sull'esperienza utente. Scelga il bastion in cui ha altri workload, oppure quello la cui giurisdizione si adatta meglio al suo modello di minaccia (vedi /guides/nordic-jurisdictions-for-privacy-hosting/).
Il tier Sentinel ($5.90/mese) è sufficiente per un hidden service che ospita un sito personale, un endpoint SSH compatibile con Tor o un piccolo mirror onion di Mastodon. I hidden service più grandi (istanza principale Mastodon, condivisione file, ecc.) richiedono Garrison o Ravelin per RAM e disco aggiuntivi.
Repository ufficiale del Tor Project, non il pacchetto della distro.
Il Tor pacchettizzato dalla distribuzione è spesso mesi indietro rispetto all'upstream e potrebbe mancare di correzioni di sicurezza. Usare il repository apt del Tor Project stesso:
apt install -y apt-transport-https gpg curl
curl -fsSL https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
| gpg --dearmor -o /usr/share/keyrings/tor-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] \
https://deb.torproject.org/torproject.org bookworm main" \
> /etc/apt/sources.list.d/tor.list
apt update
apt install -y tor deb.torproject.org-keyring
Verifichi che il daemon sia attivo: systemctl status tor — dovrebbe riportare Active (running). La configurazione predefinita non apre porte in ingresso e esegue Tor come client solo-relay; lo trasformeremo in un hidden service nel passo successivo.
Due righe in torrc. Ecco tutto.
Aprire /etc/tor/torrc e aggiungere:
HiddenServiceDir /var/lib/tor/my_service/
HiddenServicePort 80 127.0.0.1:80
Due cose da sapere. (1) HiddenServiceDir è dove Tor conserva la chiave privata del servizio (il segreto che definisce l'indirizzo .onion). Tor crea la directory al primo avvio; non modifichi il contenuto. (2) HiddenServicePort mappa la porta pubblica sull'onion su una porta locale — qui, la porta 80 sull'onion va a 127.0.0.1:80 (nginx, Apache, qualsiasi cosa ascolti localmente). Aggiunga altre righe HiddenServicePort per porte aggiuntive (HTTPS su 443, SSH su 22, ecc.).
Qualunque cosa leghi al target locale (nginx, sshd, gitea), assicurarsi che ascolti su 127.0.0.1 — non su 0.0.0.0. Un servizio legato a 0.0.0.0 è raggiungibile anche sull'IP pubblico, il che vanifica il presupposto del solo hidden service.
Riavvii Tor. Legga il file hostname.
Riavvii Tor e Tor genererà la coppia di chiavi v3 e l'indirizzo:
systemctl restart tor
cat /var/lib/tor/my_service/hostname
# example output:
# 7f43hp...long-string...7q.onion
Quella stringa base32 di 56 caratteri che termina in .onion è il suo indirizzo del hidden service. È derivata dalla chiave pubblica Ed25519 in /var/lib/tor/my_service/hs_ed25519_public_key. Chiunque abbia l'indirizzo può raggiungere il servizio tramite Tor Browser (o qualsiasi client compatibile con Tor). Lo testi: apra Tor Browser, incolli l'indirizzo, prema invio — il suo servizio web dovrebbe rispondere.
Eseguire il backup del contenuto di /var/lib/tor/my_service/ in un luogo sicuro. Perdere le chiavi significa perdere l'indirizzo .onion — non può essere recuperato. Condividere le chiavi significa che chiunque le possieda può eseguire lo stesso .onion da qualsiasi server.
Permessi, isolamento, rimozione banner. La parte noiosa ma critica.
1. Verificare che il servizio venga eseguito come utente debian-tor, non come root. apt install gestisce questo su Debian/Ubuntu. Verifichi: ps aux | grep tor — l'uid non dovrebbe essere 0.
2. Bloccare le chiavi. chmod 700 /var/lib/tor/my_service/ — solo debian-tor può leggere. Tor rifiuta di avviarsi se la directory è leggibile da tutti.
3. Rimuovere i banner del server. nginx: server_tokens off; nel contesto http. Apache: ServerTokens Prod, ServerSignature Off. Web-app: rimuova X-Powered-By, imposti Server: blank se il suo reverse proxy lo consente. L'obiettivo è che una risposta HTTP dall'.onion non riveli l'IP o il hostname.
4. Disabilitare i DNS leak in uscita. La sua applicazione web non deve risolvere nomi di dominio esterni su richiesta, altrimenti quelle query DNS lasciano il VPS tramite clearnet. Imposti l'app per usare il proxy SOCKS di Tor per le chiamate in uscita (127.0.0.1:9050).
5. Impostare Onion-Location sul proprio sito clearnet. Aggiungere questo header alla configurazione nginx clearnet: add_header Onion-Location http://<your-onion>.onion$request_uri; — gli utenti di Tor Browser riceveranno ora un prompt per il reindirizzamento automatico all'onion.
Domande, con risposta.
Otto domande che un operatore di hidden service alla prima esperienza pone.
Cos'è un indirizzo onion v3 e in cosa differisce dal v2?
Un indirizzo onion v3 è una stringa base32 di 56 caratteri che termina in .onion, derivata da una chiave pubblica Ed25519. La v2 (deprecata e disabilitata da Tor dal 2021) usava una base32 di 16 caratteri da una chiave RSA-1024 troncata — breve, ma crittograficamente molto più debole. La v3 ha una chiave più robusta (Ed25519), migliore privacy della directory (nessuna enumerazione dei servizi), supporto all'autorizzazione dei client, ed è l'unica versione ancora operativa. Se si vede un indirizzo .onion a 16 caratteri, è inattivo.
Un Tor hidden service divulga l'IP del mio server?
Uno configurato correttamente no. Tor si connette verso l'esterno dal VPS a tre relay Tor (un guard, un middle, un rendezvous) e non accetta mai connessioni in entrata direttamente sull'IP del VPS. Il hidden service è raggiungibile solo attraverso il circuito Tor. Le configurazioni errate che FANNO trapelare l'IP: eseguire il servizio su una porta pubblica (dovrebbe essere legato a 127.0.0.1), DNS leak dall'applicazione web ospitata, il software server che stampa l'IP nelle risposte in uscita. La checklist standard di seguito copre ciascun caso.
Il mio provider VPS può vedere cosa c'è nell'hidden service?
Il suo provider VPS vede traffico Tor in uscita dal suo VPS — sa «questo server esegue Tor» ma non a quale contenuto si accede. Non può vedere cosa c'è nel hidden service dall'esterno; può vedere cosa c'è sul disco dall'interno, come qualsiasi provider VPS. NordBastion non accede ai dischi dei clienti, ma un server che non controlla con cifratura completa del disco è un server che un operatore può teoricamente leggere. Per la privacy assoluta del hidden service, esegua LUKS con una passphrase che solo Lei conosce — Servury lo confeziona out of the box su hardware di proprietà, altri (NordBastion incluso) lo lasciano come installazione a cura del cliente.
Come si ottiene un indirizzo .onion personalizzato (ad es. che inizia con il nome del brand)?
Usi mkp224o — uno strumento open-source che esegue brute-force su coppie di chiavi Ed25519 finché l'indirizzo v3 risultante non inizia con un prefisso scelto. Un prefisso di 4 caratteri si trova in minuti su un laptop moderno; un prefisso di 7 caratteri richiede qualche ora; 10+ caratteri richiedono settimane o mesi su hardware dedicato. L'indirizzo onion risultante è crittograficamente valido — il brute-force trova solo la chiave la cui parte pubblica hash inizia con i caratteri desiderati.
Quanto è veloce un hidden service?
Più lento della clearnet. Tor instrada attraverso tre relay, quindi ogni round-trip aggiunge ~300-800ms di latenza. Il throughput è limitato dal relay più lento nel circuito scelto; si aspetti 1-5 MB/s in media per contenuti statici, meno per workload interattivi. Tor ha introdotto ottimizzazioni «HSDir bandwidth» e HiddenServiceSingleHopMode per i casi in cui l'anonimato lato servizio non è richiesto.
Devo usare HiddenServiceSingleHopMode?
Solo se il proprio modello di minaccia accetta che il lato SERVIZIO sia noto pubblicamente (ad es., si è già pubblicato «questo onion gira sul mio server in Islanda»). La modalità single-hop salta i relay guard+middle sul lato servizio e si connette direttamente al rendezvous, che è più veloce (200-400ms di latenza in meno) ma non protegge l'IP lato servizio. I client ottengono ancora la piena privacy a tre hop dal loro lato. Per un hidden service che necessita di anonimato lato server, lasciarlo disabilitato (il default).
Posso eseguire un hidden service sullo stesso VPS del mio sito clearnet?
Sì, e molti siti lo fanno. Il web server clearnet ascolta sull'IP pubblico alle porte 80/443; il hidden service Tor punta allo stesso web server su 127.0.0.1 sulle stesse porte. Entrambi raggiungono lo stesso contenuto. Due note operative: (1) assicurarsi che il web server non inserisca l'IP pubblico negli header (Server, X-Real-IP, banner hostname), e (2) impostare l'header HTTP Onion-Location sul sito clearnet così gli utenti di Tor Browser vengono reindirizzati automaticamente all'indirizzo onion.
Cos'è Vanguards / Vanguards-lite?
Un add-on Tor (Vanguards) che fissa il relay guard lato servizio, mitigando una classe di attacchi in cui un attaccante osserva quali guard il servizio ruota e li usa per deanonimizzare. Vanguards-lite è integrato nel daemon Tor dalla versione 0.4.7 e abilitato di default per i hidden service nelle versioni Tor correnti — in genere non è necessario fare nulla per beneficiarne. Il Vanguards add-on completo è eccessivo per la maggior parte dei hidden service personali e utile principalmente per obiettivi ad alto valore.
Ordinare un VPS e mettere il proprio servizio sull'onion.
Ultima revisione · 2026-05-20 · Testato · Debian 12 · Tor 0.4.8+
Anonymous VPS hosting in 2026 — the cluster.
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Your own WireGuard tunnel — server config, peer keys, kill-switch.
What “no KYC” actually means — and what it does not.
Why Sweden, Finland, Norway and Iceland — the legal floor of each.
XMR end-to-end — wallet, transfer, confirmations, change.