The baseline security practices every independent infrastructure operator should have in place.
If you're self-managing your own Linux server — a Colonist-tier setup, your own VPS, whatever you want to call it — the security of that box is entirely your responsibility. Nobody's going to notice a misconfigured firewall rule for you. Nobody's watching your logs unless you set that up yourself. This isn't meant to be alarming, just accurate: self-management means the baseline has to actually be a baseline, not an afterthought.
Here's what that baseline should include.
The Baseline Most Self-Managed Servers Skip
The hosting industry has trained a lot of people to think of security as a stack of add-ons — malware scanning here, a firewall there, backups as a separate line item. That framing is backwards. Security isn't a set of features bolted onto infrastructure. It is infrastructure. A server without hardened access, patching, and monitoring isn't a server with a missing add-on — it's an unfinished server.
Lock Down Access First
Access control is where most compromises actually start, and it's also the cheapest thing to get right.
- SSH key authentication, not passwords. Disable password authentication entirely. Keys are dramatically harder to brute-force, and they remove an entire category of credential-stuffing risk.
- Disable root login over SSH. Use a named user with sudo access instead. This isn't just about slowing down attackers — it gives you an actual audit trail of who did what.
- Never use FTP. Ever. FTP transmits credentials and file contents in plain text. Anyone positioned on the same network — a compromised router, a malicious access point, an ISP-level intercept — can read everything going over that connection. SCP and rsync over SSH give you the same functionality, encrypted, with no plaintext exposure. There's no legitimate reason to still be using FTP on a server you care about.
- Change the default SSH port if it fits your threat model. This won't stop a targeted attacker, but it dramatically cuts down on the automated noise from mass scanners hitting port 22.
Perimeter Defense Basics
Every server on the public internet gets scanned and probed constantly — that's just the environment, not a sign you're specifically targeted. What matters is what your server does in response. At minimum, you want something watching failed login attempts and automatically banning IPs that show clear brute-force patterns, with escalating lockout periods for repeat offenders. You also want basic rate limiting on anything public-facing, so a scripted flood of requests doesn't get to hammer your application layer unchecked.
Tools like fail2ban handle the SSH side of this well. The web application side needs its own layer, which is where a lot of self-managed setups fall short — perimeter defense on the network level doesn't help you if the attack is coming through a web form or a vulnerable plugin.
Keep Everything Patched
This is the least glamorous item on this list and also one of the highest-leverage. Enable automatic security updates for your OS packages at minimum. For application-level dependencies — your CMS, your framework, your language runtime — set a real cadence for checking and applying updates rather than waiting for something to break. The overwhelming majority of real-world server compromises exploit known vulnerabilities that already had a patch available. Staying current isn't glamorous work, but it closes more doors than almost anything else on this list.
Principle of Least Privilege
Every process, every database user, every API key should have exactly the access it needs and nothing more. A web application's database user doesn't need permission to drop tables if all it ever does is read and write rows. A backup script doesn't need write access to production data. This is tedious to set up correctly and it's exactly the kind of control that turns "an attacker got a foothold" into a contained incident instead of a total compromise.
A Web Application Firewall Is Not Optional
SQL injection, cross-site scripting, shell upload attempts, known exploit signatures — a WAF sitting in front of your application catches a huge share of this before it ever reaches your code. Treating a WAF as a premium upsell, the way a lot of budget hosts do, means the baseline security posture of "cheap" hosting is quietly worse than it looks on the pricing page.
Backups Are Part of Security, Not a Separate Task
A security incident you can't recover from is a much worse day than a security incident you can. Automated, regular backups with multiple recovery points — not just "a backup," but enough history that you can roll back to before an issue started, not just to yesterday — are as much a part of your security posture as your firewall rules. And test your restores occasionally. An untested backup is a hypothesis, not a plan.
What We Automate So You Don't Have To
Everything above is genuinely manageable for a competent self-managed operator — that's exactly who our Colonist plan is built for. But it's also, in aggregate, a meaningful amount of ongoing operational overhead: monitoring logs, tuning WAF rules, keeping ban lists current, verifying backup integrity, watching for the malware and backdoor patterns that don't show up in a simple failed-login count.
That's the specific gap Minuteman Protection™ is built to close — perimeter defense, a web application firewall, malware and backdoor detection, infrastructure integrity monitoring, and 14-day rolling backups, running continuously, included standard on every plan we offer. Whether you're handling all of this yourself or want it handled for you, the baseline shouldn't change. Only who's watching it does.