Server security basics: where to start

Who's knocking (and why it isn't personal)

Give a server a public IP and its access log will show dozens of login attempts from addresses all over the world before you've even finished setting it up. None of it is aimed at you personally. It's bots sweeping whole ranges of the internet around the clock, trying common usernames and passwords, poking at unpatched services and hunting for doors someone left open.

That reframes the problem. Nobody is too small to get scanned — at internet scale, “small” means nothing — so the aim isn't to hide, it's to not be the easy mark. Most of these bots want a soft target: give a machine a bit of resistance and they hop to the next address. Almost all of basic security comes down to that.

Layers, from the outside in

One idea holds the rest together: don't lean on a single barrier. Each layer takes it for granted that the one before it might fail, and limits the damage when it does. That's defence in depth, and it's easiest to picture from the outside in.

The order is the whole point. The firewall filters before traffic touches anything; access control guards whatever the firewall lets through; and only once you've trimmed away everything unnecessary is there a single service facing the world. Underneath, as a net for whatever slips past, sit your backups and your monitoring. No layer is airtight on its own — stacked, they turn a breach into a scare rather than a catastrophe.

Access: the door that gets hammered most

Remote access over SSH is the first thing bots probe, so it's the first thing worth hardening. Three choices cover nearly everything:

• Log in with a key, not a password. An SSH key is a pair of cryptographic files — one stays on your computer, the other on the server. A machine can grind through an eight-character password given time; grinding through a key of this kind is, in practice, off the table. Once it's set up you can turn password login off entirely, and brute force against the login stops meaning anything.
• Don't log in as root. The all-powerful admin account is the one every attacker tries by name. Disable its direct access and work as an ordinary user who elevates privileges only when needed — that way even a successful break-in doesn't hand over the keys to the whole kingdom.
• Keep only the accounts you use. Every live account is another door. Leftovers from people who've moved on, or ones spun up “just to test” and forgotten, are a staple of security audits.

The noise won't stop — they'll keep knocking — but it stays harmless noise.

Open only what you must: the firewall

A server shouldn't expose anything to the world that the world doesn't need. The rule is deny everything by default and open only the essential ports — usually the web and remote access, not much else. Every open port is one more surface someone can probe, so a short list always wins.

The common slip isn't forgetting the firewall; it's exposing an internal service by accident. A database is the textbook case: it has no reason to listen on the public address when only the app on the same machine ever talks to it. Bind it to the local interface (127.0.0.1) and it vanishes from the outside even if the firewall had a gap. Admin tools, internal dashboards and debug ports belong in the same bucket — handy indoors, a gift if they peek out onto the internet.

Patch before they do

A lot of attacks use nothing clever at all: they exploit flaws that are already known and already fixed, against machines that never applied the patch. When a security flaw goes public, so does the recipe to exploit it, and automated scanners fold that recipe in within days. The gap between “a patch exists” and “it's being hit at scale” is short.

Staying current doesn't mean flipping everything to automatic and looking away. It's worth separating security updates — apply those fast, and they can be automated sensibly — from big version changes, which deserve testing first. And one thing people forget: some updates, kernel ones especially, only take effect after a reboot. A patched server that hasn't restarted in months may be carrying a hole it thinks it has closed.

Throttle the brute force

Even with password login switched off, everything else keeps taking attempts — panels, mail, forms. A simple, high-value guard helps here: a watcher that reads the logs, counts the failures and blocks the offending IP. Ten wrong passwords in a minute from one address isn't a forgetful user; it's a machine trying its luck, and the door shuts on it for a while.

It's one of the best effort-to-payoff measures going: set it up once and it kills dictionary attacks — the bulk of them — stone dead. The only real care is not locking yourself out (keep your own address on an exceptions list) and setting the threshold so a genuine fat-fingered typo doesn't earn a ban.

The one thing left facing the world: the service

Once you've trimmed everything else, one thing stays exposed on purpose: the application doing the actual work. That earns it separate care.

• Don't run it as root. If a fully privileged service has a flaw, whoever exploits it inherits all those privileges. Run it as a limited user and the same flaw stays boxed into its corner.
• Encrypt the traffic. TLS — the padlock behind https — keeps credentials and data from crossing networks you don't control in the clear. It's free and automatic now; skipping it has no excuse.
• Keep secrets out of the code. Passwords, API keys and tokens don't belong in the repository or in a file that might get served by mistake. A secret that lands in a repo's history should be treated as burned and rotated.
• Mind your dependencies. The code you write is a sliver of what runs; the rest is third-party libraries. Keeping them current matters as much as patching the system itself.

For when something goes wrong anyway: backups and monitoring

Perfect security doesn't exist, and behaving as if it did is the most expensive mistake on the list. The two nets that catch you when something gets through are backups and monitoring — and both have a catch.

A backup only counts if it meets three conditions: it lives off the machine (a copy on the same server, encrypted or wiped along with it, is worthless), it's automated so it never rides on someone happening to remember, and — the one almost everyone skips — it has been restored at least once. Run a recovery drill every so often.

Monitoring is the other half, and it doesn't need an operations centre: just an alert when something drifts out of normal — a disk nearly full, a service down, an odd spike in access, a process that shouldn't be there. Finding out in ten minutes instead of ten days is the difference between a nuisance and making the news.