Securing a personal server depends less on exotic settings than on an order of operations. Following the right steps in the wrong order leaves gaping holes, and that is where most "secured" installations fail. Here is the detailed step-by-step guide, and why this particular order. It is the practical follow-up to taking back control of your server.
The order makes it hold
A server's security isn't a pile of settings stacked at random: it's a sequence where each step assumes the one before. Opening access before closing everything by default is like protecting a house whose door stayed open throughout the renovation. The order runs from the most structural step, reducing the surface, to the finest, hardening what remains.
What I take from it — Security is a sequence, not a list. The order makes it hold.
Step by step
- Close it, and remove the password. Firewall set to deny by default; open only the strict minimum. Admin access by cryptographic key alone: no password, which removes anything a bot could guess. And the bots arrive fast: in Sophos's 2019 study of ten decoy servers, the first was attacked 52 seconds after going live, and each one absorbed thirteen attempts per minute for thirty days. Access restricted to known addresses.
- Make internal traffic invisible. Everything internal runs on an encrypted private network, unreachable from the internet. Only the services that must be exposed stay exposed, behind authentication. Check from the outside, not from your own machine: that's how you discover a service you thought was private was actually open.
- Back up immutably, and test it. Three copies, two media, one off-site, one immutable (locked in time, which ransomware can't erase). A versioned backup tool rather than a plain mirror. And above all: actually restore at least once. An untested backup is a hypothesis.
- Post a watchdog. An automatic check that warns you when an expected backup didn't happen. The dangerous failure is the silent one: without this alert, you discover the hole the day you fall into it.
- Scan and detect. A regular scan for known flaws in your software, while pinning a known-good version of the tool itself. This isn't a theoretical precaution: on March 19, 2026, Trivy, one of the most widely used vulnerability scanners, was itself compromised, with a trojanized binary, hijacked GitHub Actions and exfiltrated CI secrets. And a file-integrity monitor for system changes.
- Harden the host, last. A few targeted system settings, without falling into the security theater that costs time without reducing any real risk. Aim for "solid", not "100 on a scanner".
What I take from it — Reducing the surface (1-2) comes before hardening (6). You protect first by removing.
What will cost you time
- Some configuration files mounted read-only freeze if you edit them the wrong way: the service stays on the old version without reporting anything. You spend an hour wondering why your change has no effect.
- Automated security reports sometimes cry wolf, flagging "critical" updates that aren't. Check before acting: panicking over a false signal costs more than ignoring it.
- Sovereignty has a price: you are the operations team. Expect things to break, and above all plan how you'll find out.
What I take from it — Check before acting. A false signal handled in a panic costs more than the threat it announced.
The complete template
I've turned this step-by-step guide into a repeatable installation: scripts ready, order respected, hardening included. If you'd rather start from a sound base than a blank page, without losing weeks to it, that's what I do at Orogen. Write to me, let's talk.
Sources
- Sophos, Exposed: Cyberattacks on Cloud Honeypots, April 2019 — ten decoy servers on AWS, first attack 52 seconds after going live (São Paulo), 13 attempts per minute, more than 5 million attacks in thirty days — sophos.com.
- Aqua Security, security advisory GHSA-69fq-xp46-6x23, Trivy ecosystem supply chain temporarily compromised, March 2026 — github.com; Microsoft Security analysis, March 24, 2026 — microsoft.com.