The security baseline a small VPS actually needs

What is actually attacking you

It is worth being precise, because the mental image people carry is wrong and it leads them to spend effort in the wrong places. A new VPS is not being studied by a person. It is being swept by programs looking for a handful of things: SSH that accepts passwords, an admin path with a weak login, an application with a known unpatched hole, an exposed database port, and files that should never have been readable — .env, .git/config, a stray database dump.

The defence is therefore not clever. It is coverage, and the order below is roughly the order of how much risk each step removes per minute spent.

1. Close the doors you are not using

Default-deny inbound, allow the ports you actually serve. On a typical web server that is HTTP, HTTPS, SSH and, if you host mail, the mail ports. Database and cache ports have no business being reachable from the internet; bind them to localhost and let the firewall refuse them as well, because two layers cost nothing and one of them will eventually be misconfigured.

2. Make SSH boring

Keys only, no password authentication, and no direct root login. This single change removes the entire category of credential-guessing attacks that make up most of what you will see in your auth log. Keep a second way in — your provider's console — and test it before you need it, because the day you lock yourself out is otherwise a very long day.

3. Ban the repeat offenders automatically

Fail2ban, or an equivalent, reads the logs and blocks addresses that fail repeatedly: SSH attempts, panel logins, obvious scan patterns. It will not stop a targeted attacker, and it is not meant to. It stops the noise, which is 99% of the volume, and it keeps your logs readable enough that you can see the 1%.

4. Put a limit on how fast one address may ask

Rate limiting at the web server is the cheapest protection against both floods and credential stuffing. Two numbers matter: requests per second per address, and the burst you tolerate, because opening a single page legitimately requests dozens of files at once. Set the burst too low and you will block real visitors; too high and the limit does nothing. Start generous, then watch what real traffic does before tightening.

A connection limit per address is the companion measure: it is what stops the attacks that hold connections open rather than sending requests quickly.

5. Hide what should never have been served

Deny requests for dot-files, version control directories, backup archives and editor leftovers at the web server level, for every site, once. This is a three-line rule that closes an entire family of breaches that begin with somebody downloading your .env file.

6. Patch, and know when you have not

Unattended security updates for the system, and a habit for the application layer. The uncomfortable truth of most compromises is that the hole had a published fix weeks earlier. What you want is not perfect discipline but visibility: something that tells you plainly that updates are pending.

7. Back up, and restore once on purpose

A backup you have never restored is a belief, not a backup. Schedule it, keep enough copies to survive a problem you do not notice for a week, keep one copy off the machine, and restore into a scratch directory once so you know the procedure and the timing. Ransomware aside, the likeliest thing you will ever restore from is your own mistake.

8. Only then, the nice-to-haves

Country blocking, bot challenges, web application firewall rules and malware scanning are all worth having, and none of them substitutes for the seven steps above. Apply them where traffic justifies them: block a country only if you genuinely do not serve it, and remember that a block stops new connections rather than existing ones.

Doing it without assembling it yourself

Every item on this list is a package, a config file and a decision. That is a couple of evenings the first time and a forgotten detail every time after. ServerPanel ships the list as screens: firewall rules, fail2ban jails with the banned addresses visible, per-site rate and connection limits, honeypot paths, country blocks, a scanner and an alarm engine that watches the logs and blocks what it recognises — with the reasoning shown rather than hidden, so you can disagree with it.

The live demo has all of those screens with sample data if you want to see the shape of it before installing anything.