Bitcoin node security basics

Bitcoin node security is less about guarding private keys — Core does not store them by default — and more about not turning your box into a remote-controlled API for strangers. Most incidents in home setups trace to exposed RPC, stale OS images, or reused weak passwords on the host — not novel Bitcoin exploits.

RPC: the line you do not cross

Bitcoin Core's RPC listens on port 8332 by default. Wallets and scripts talk to it for status and raw transactions. If RPC is reachable from the public internet without rigorous auth, attackers can abuse your node — chain queries, mempool manipulation, or worse if you later enable dangerous flags.

Default safe posture:

• rpcallowip=127.0.0.1 — only local processes
• Do not set rpcbind=0.0.0.0 unless you are an advanced operator with firewall + auth
• Never port-forward 8332 on your router

Our setup guide ships with localhost-only RPC in the sample config.

Firewall checklist

Home Linux: use ufw or nftables. Allow SSH from your LAN only if you need it. Allow 8333/tcp only if you want inbound peers. Block everything else inbound by default.

VPS: provider firewalls plus OS firewall. Close all ports except SSH (prefer key-only auth) and optionally 8333. Treat the VPS hypervisor as a trusted-but-not-yours layer — see VPS privacy notes.

$ sudo ufw default deny incoming
$ sudo ufw allow OpenSSH
$ sudo ufw allow 8333/tcp comment 'Bitcoin P2P'
$ sudo ufw enable

OS updates and user separation

Run bitcoind as a dedicated unprivileged user (see setup guide systemd unit). Apply security updates monthly — unattended-upgrades on Debian/Ubuntu is fine for home nodes. Reboot when kernels ship; Bitcoin Core survives clean restarts with systemd restart policies.

Do not install random curl|bash node dashboards from forum threads. Stick to Bitcoin Core binaries verified from bitcoincore.org.

SSH hygiene

• Disable password auth; use keys
• Fail2ban or provider equivalent on VPS
• Non-default SSH port is optional obscurity — not a substitute for keys

Backups worth having

You do not backup the chain — you can re-download. Backup:

• bitcoin.conf and any custom scripts
• Systemd unit files
• Wallet.dat only if you created a Core wallet (most hardware wallet users have none)

What a node does not protect

• Phishing that steals seeds
• Malware on your laptop
• Exchange insolvency
• Blockchain surveillance of your spending patterns if your wallet leaks addresses

Pair node security with wallet discipline and realistic privacy expectations — Tor guide covers network-layer limits honestly.

Upgrade discipline

Bitcoin Core releases on a predictable cadence. Subscribe to release announcements, verify signatures, stop cleanly with bitcoin-cli stop, replace binaries, restart. Running EOL versions is how soft forks and DoS fixes pass you by.

Quick audit script (read-only)

$ bitcoin-cli getnetworkinfo | grep -E 'networkactive|connections'
$ ss -tlnp | grep -E '8332|8333'
# 8332 should bind 127.0.0.1 only

Authentication and RPC passwords

Bitcoin Core generates an RPC cookie file for local authentication when you do not set rpcpassword. That is fine for localhost-only setups. If you must allow LAN wallets, use explicit rpcauth lines with strong random passwords — never reuse exchange passwords. Rotate after any suspicion of LAN compromise.

Do not enable server=1 with wide rpcallowip ranges "temporarily" during sync — temporary misconfigurations become permanent attack surface when you forget to revert.

Logging and monitoring

You do not need a Grafana dashboard. Useful minimum:

• journalctl -u bitcoind -n 50 after reboots or upgrades
• bitcoin-cli getconnectioncount — zero peers for days means network or firewall issues
• Disk alerts via df -h cron email or provider monitoring on VPS

Logs can contain peer IPs. Treat them as sensitive if you run Tor for privacy — redact before sharing in support forums.

VPS-specific risks

On a VPS, your threat model includes the hypervisor admin, neighbor VMs on oversubscribed hosts, and stolen API keys for the provider console. Mitigations:

• Full-disk encryption where the provider supports it at rest
• Separate SSH keys per server; no password reuse
• Disable provider "rescue mode" auto-login if offered
• Assume law enforcement can seize the instance — do not host anything illegal; do not store seeds on the node machine

See VPS comparison for bandwidth and disk notes before you expose a node to the public internet from a datacenter IP.

Incident response (simple)

If you suspect RPC exposure:

1. Block 8332 at firewall immediately
2. bitcoin-cli stop and inspect bitcoin.conf for unexpected rpcallowip
3. Review auth logs (/var/log/auth.log) for SSH brute force
4. Upgrade Bitcoin Core if you were on an old release with known CVEs

No panic wallet moves are required if you never stored keys on the node — verify that assumption before wiping disks.

Hardware placement

Physical access matters for home nodes. A mini PC in a closet is fine; leaving RPC open on a laptop on café Wi-Fi is not. Pick hardware with headroom — underpowered boxes tempt people to disable security for convenience. See hardware comparison for stable 24/7 options.

FAQ