Hidden-service node — security checklist before going public

Privacy & Networking
1

Hidden-service node — security checklist before going public

If you’re running an INTcoin node behind Tor (.onion) or I2P (.b32.i2p) and want to advertise the address publicly so other peers can connect, this thread documents the basics. Skipping any of these turns your “private node” into something that’s accidentally leaking real-world identity.

1. Never bind RPC to anything but loopback

# intcoin.conf — REQUIRED
rpcbind=127.0.0.1
rpcallowip=127.0.0.1

If rpcbind=0.0.0.0 is set (and it shouldn’t be), then every Tor / I2P peer that connects to your hidden service can also hit your RPC port if you’ve forwarded that. RPC carries dumpprivkey — don’t expose it to the world.

The fleet bind RPC to LAN inside the UK datacenter (so internal mainnet miner UK-B can talk to UK-A’s RPC) but never to WAN. Same rule for hidden-service operators: RPC stays loopback.

2. Don’t co-locate sensitive workloads with the hidden service

If your intcoind runs on the same machine as your daily-use desktop, your password manager, your 2FA tokens, etc., a remote-code-execution bug in intcoind compromises all of those. Hidden-service operators tend to be paranoid about node bugs because the upside of running publicly known onion is that you ARE a known target.

Recommended: hidden service intcoind runs in a dedicated VM or container with no shared user account, no shared SSH key, no host-volume mount of your wallet. Use WalletDir=/wallets-readonly/ mounted read-only if you want the node to validate but never sign — i.e., a watch-only node serving the network without itself being a signing target.

3. Run Tor and I2P from upstream packages, not bundled versions

INTcoin’s intcoind doesn’t bundle Tor or I2P daemons — you install them from your distro:

# Debian/Ubuntu
sudo apt install tor i2pd

# Arch
sudo pacman -S tor i2pd

# macOS via brew
brew install tor i2pd

Reasons:

  • Distro packages get security patches via apt upgrade / pacman -Syu. A bundled Tor would lag.
  • Tor’s threat model assumes an unprivileged user, NOT root. Distro packages run Tor as the _tor (Debian) or tor (Arch) user automatically.
  • You can audit the Tor config independently of intcoind — /etc/tor/torrc is human-readable; bundled config is harder to spot-check.

4. Hidden Service Authentication if you don’t want truly public access

If your goal is “I want a few specific peers to connect via Tor”, not “anyone in the world can connect”, use Tor’s client authorization feature:

# /var/lib/tor/intcoin-hs/authorized_clients/peer1.auth
descriptor:x25519:<base32-pubkey>

Without the matching private key, peers can’t connect to your hidden service even if they know the .onion address. This is the threat model you want for a small-group node.

For a fully public seed node (advertised on the project’s seed list), don’t use client auth — the whole point is open connectivity. But still:

5. Rate-limit at the iptables / nftables layer

Public hidden-service nodes get probed constantly. Without rate-limiting, a single attacker can fill your peer slots with junk handshakes:

# iptables rate-limit P2P port to ~30 connections / 60 seconds per source
iptables -A INPUT -p tcp --dport 2210 -m conntrack --ctstate NEW \
    -m hashlimit --hashlimit-name intcoin --hashlimit-mode srcip \
    --hashlimit-above 30/minute -j DROP

For Tor / I2P this is tricky because the apparent source is always Tor’s local SOCKS proxy — but that’s actually fine, because Tor itself has a circuit limit per relay so you get implicit rate limiting from the network layer.

6. Don’t leak your real IP via DNS / NTP / Other

intcoind itself uses Tor’s SOCKS proxy for outbound connections when -onion= is configured, and has its own DNS-over-Tor logic. But your system is still doing other things:

  • NTP: most distros default to pool.ntp.org over clearnet. That leaks “I exist on this IP at this time” to NTP server operators. Set Chrony to use Tor-tunneled NTP relays, OR run ntp over your VPN. (Or accept the leak — clock-skew leaks are weak signals on their own.)
  • System logs uploaded: journald.cloud-uploader and similar phone home. Disable.
  • Auto-update services: unattended-upgrades, pacman -Syu cron, brew autoupdate. These hit clearnet. Either tunnel them through Tor or disable + manual-update.
  • Email: postfix / sendmail will dial out if the node sends email (cron mail, etc.). Either disable or route through a Tor exit.

7. Your wallet HD seed is your real identity — protect accordingly

The hidden service .onion address is public by design (you’re advertising it). The HD wallet seed is private by design (it controls your INT). Both live on the same machine if you’re not careful.

Strongly recommended: the hidden-service node should NOT contain a hot wallet. Use it as a watch-only / relay node only. Sign transactions on a separate cold machine via PST workflow, broadcast via the hidden-service node’s sendrawtransaction. That way an intcoind 0-day on the public-facing machine costs you nothing financially.

8. Rotate the .onion if it leaks

Tor v3 onion addresses are derived from an ed25519 keypair. If the keypair leaks, an attacker can impersonate your hidden service. Rotation:

sudo systemctl stop tor
sudo rm -rf /var/lib/tor/intcoin-hs/
# Re-create the HiddenServiceDir entry in torrc (Tor regenerates the key on next start)
sudo systemctl start tor
sudo cat /var/lib/tor/intcoin-hs/hostname

The new .onion address replaces the old one. Update wherever you’ve published it (signal to peers, signed announcement, etc.) and abandon the old one.

9. Do NOT publish your .onion in places that link to your real-world identity

If your forum username is “alice@example.com” and you post your .onion address with that username, you’ve just told the world that alice@example.com runs that node. Use a separate handle for hidden-service-related posts, ideally on a forum / IRC channel that itself is over Tor.

10. Consider a “split-personality” setup

Many hidden-service operators run two intcoind instances:

  • Public-facing: clearnet IP, advertised in seed lists, validates + relays only, no wallet, no RPC exposed.
  • Private-facing: Tor-only outbound, your real wallet, RPC available locally only, talks to the public-facing one over LAN.

This decouples the “I want to participate in peer relay” goal from “I want my wallet private.” The public node carries no signing material, so its compromise is annoying but recoverable. The private node never accepts inbound connections, so it can’t be probed remotely.

This isn’t an exhaustive opsec guide — operating a privacy node well is a big topic. But getting these ten right covers ~80% of “I accidentally deanonymised myself” failure modes from the broader privacy community’s incident reports.

— INT-devs

(Cross-references: Running INTcoin over Tor — full setup, Running INTcoin over I2P — setup guide, V2 post-quantum transport — how every connection is encrypted.)