A blockchain node server is scanned within minutes of getting a public IP address. Automated bots try common usernames, guess passwords, and probe every open port, not because they know you run a node, but because they probe everything. Node servers are attractive targets for a specific reason: they hold validator keys, RPC access, and sometimes wallet material, and a compromised node can be used to steal stake, serve false chain data, or mine on your bill. Security hardening is therefore not a later task. It is the first task, before the node software is installed.
The order of operations matters more than any single setting. Create a non-root user, set up SSH key login, test it from a second session, and only then disable password login. Set firewall rules, and only then enable the firewall. Operators who reverse either order lock themselves out, and the recovery - through a provider console, if one exists - wastes the first day of a setup. Every step below follows that order, and every step can be verified before moving to the next.
SSH keys first, passwords off second
Generate an Ed25519 key pair on your own machine, not on the server, and copy the public key to the server with ssh-copy-id or by appending it to the authorised keys file for your non-root user. Test login with the key from a new terminal session, while keeping your existing session open. Only when key login works, edit the SSH daemon configuration: set PermitRootLogin to no, PasswordAuthentication to no, and PubkeyAuthentication to yes, and consider MaxAuthTries 3 and LoginGraceTime 20 to limit guessing. Restart the SSH service and test again from a new session before closing the old one.
Changing the SSH port from 22 to a non-standard port reduces log noise from automated scans, but it is not security by itself. A port scan finds any port, and a hardened port 22 is safer than a weak custom port. Treat a custom port as noise reduction, not as a control, and never rely on it in place of key-only login. Similarly, restricting SSH to specific source IPs is strong when your IP is stable, and a lockout risk when it is not. If you restrict by IP, keep provider console access as a fallback, and test it before you need it.
Firewall: allow first, enable second
UFW, the Uncomplicated Firewall, is Ubuntu default firewall tool, and its rules are simple enough to get exactly right. Set the defaults first: deny incoming, allow outgoing. Then allow SSH before anything else - if you changed the port, allow that port, not port 22. Only then enable the firewall and check the status with verbose output. The classic lockout is enabling UFW before allowing SSH, and it happens to experienced operators, not just beginners, because the enable command warns that it may disrupt existing connections and it is easy to answer yes while thinking about the next step.
For a node server, open only the ports your chain actually needs. Ethereum guidance commonly lists execution client peer traffic on 30303 for both TCP and UDP, and consensus client peer traffic on 9000 for both TCP and UDP, with exact ports varying by client. Open those, plus SSH, and nothing else by default. Do not expose RPC ports to the internet: an RPC endpoint open to the world lets anyone query your node, and depending on enabled methods, submit transactions or read sensitive data. RPC should listen on localhost, or behind authentication and a reverse proxy, or on a private network only. Database ports, monitoring dashboards, and validator APIs follow the same rule: localhost or private network, never public, unless you have deliberately secured them.
Fail2ban, updates, and the habits that keep it secure
Even with password login disabled, bots will still hammer SSH with handshakes, wasting resources and filling logs. Fail2ban watches authentication logs and bans repeat offenders at the firewall, which quiets the noise and reduces load. Install it, copy its default jail configuration to a local override file, and check that the SSH jail is active. Fail2ban is a supplement, not a replacement: it does not fix weak keys, open RPC ports, or unpatched software, and it should never be the only control you can name.
Automatic security updates close the other common hole. Enable unattended upgrades for security patches, and schedule a regular maintenance window for everything else, including client upgrades, which need the testnet-first discipline covered in earlier posts. Reboot after kernel updates when the schedule allows, and verify the node resyncs cleanly after reboot rather than assuming it. Finally, keep an audit habit: review firewall rules and logged-in users monthly, rotate SSH keys when a team member leaves, and remove accounts that are no longer used. A server that was secure on setup day drifts insecure by accumulation, one forgotten account and one opened port at a time.
The checklist for a new node server fits on one page: non-root user, Ed25519 key login tested, root and password login disabled, UFW deny-by-default with SSH allowed before enabling, only chain peer ports open, RPC on localhost or private network, Fail2ban active, automatic security updates on. If any item on that list is unverified, the server is not ready for mainnet keys, however well the node software runs. If you are hardening an existing node, or setting up your first production validator server, blockchain node setup and DevOps node operations cover hardening, firewall design, and monitoring, starting with a free infra audit. Bring your current firewall rules and SSH configuration: those two outputs reveal most node server security problems in minutes.
Disclaimer: This post is educational only, not financial advice. Figures are listing or project data as of 2026-10-30 and may change - always confirm version numbers, requirements, and dates in the official docs before acting on them.