VPS Security Audit: 7 Gaps Hiding on a Self-Managed Server
A VPS security audit usually finds gaps nobody meant to leave open. Here are seven common ones, and how to close each without breaking a live site.
Most of us who run a self-managed VPS assume it is fine. We set it up ourselves, so we think we know what is on it. Then we actually run a VPS security audit, read the configuration line by line, and find a list of open doors nobody meant to leave open.
The gaps are rarely exotic. They are almost always installer defaults that were never switched off. A control panel locked down tightly while a second panel beside it sits wide open. SSH still accepting a root password from anywhere on the internet. A firewall holding thousands of ports open for software that is not even running.
If you host client sites on a server you built yourself, the same defaults are probably sitting on your box right now. Here is what to look for and how to close each gap safely.
Why a VPS security audit matters when you host client sites
Managed hosting hides this work from us. A decent host patches the operating system, closes unused ports, and configures the mail stack sensibly before anyone logs in.
Moving to a self-managed VPS quietly transfers all of that to us. The server never complains. It runs perfectly well with an unlocked side door, right up until somebody finds it.
That is the uncomfortable part. A compromised VPS does not affect one person. It affects every site sitting on it, and when those sites belong to clients, a defacement or a data leak becomes their problem too.
Seven gaps a VPS security audit usually turns up
Vague advice about hardening a server helps nobody, so here are the specific things worth checking.
1. A locked front door and an unlocked side door
Control panels often ship in pairs: an admin panel and a companion user panel on a nearby port. It is common to find the admin panel properly restricted, with an IP allow list, a one-hour block after five failed logins, a 30-minute idle timeout, and HTTPS enforced, while the user panel beside it has none of that.
No IP restriction. No two-factor option switched on. No idle timeout, so a session opened hours earlier is still valid. A lockout that bans an attacker for 60 seconds. Same server, same password file, completely different posture. If nobody uses that second panel, it is pure risk with no benefit.
2. SSH that still accepts a root password
Check for root login permitted and password authentication left at its default, which is usually on. That pairing lets anyone on the internet sit there guessing the root password all day.
3. Firewall rules guarding nothing
Installers tend to be generous. A typical audit finds FTP ports open with no FTP server running, including a passive range that can cover more than sixteen thousand ports. Local network discovery services are often allowed on a public server where they serve no purpose. Panel ports are frequently opened as a block of a hundred when exactly one is in use.
4. Updates sitting in the queue
Pending operating system and panel updates are easy to ignore because nothing visibly breaks. A server one version behind is a server where somebody else has already read the changelog.
5. A self-signed certificate on the panel
Self-signed certificates train us to click through browser warnings. Once that habit forms, a genuine warning stops registering.
6. Intrusion detection with toothless defaults
Tools like Fail2Ban are often installed and running, which looks reassuring. Then the detail turns out to be a ten-minute ban, no escalation for repeat offenders, and alert emails pointed at a local mailbox nobody reads.
7. Site accounts with full shell access
Hosting panels commonly give every site account a full login shell. One hacked WordPress install then hands an attacker a foothold on the whole machine rather than a single site directory.
Audit first, change nothing
The most useful rule is to read everything before touching anything. No changes, no quick fixes along the way.
This matters more than it sounds. The instinct on spotting an open port is to close it immediately, and that is exactly how people lock themselves out of their own server late at night. Read first, write down what you find, then decide the order of the work.
Fix one item, then prove it saved
Work the list one item at a time and verify each one before moving on.
That discipline pays off quickly. A panel can show a setting as switched off while the stored value is still switched on, which means the service comes straight back on the next reboot. The only way to catch it is to reload the page and confirm the saved value rather than trusting what the screen shows.
Batch five changes together and that kind of silent failure slips through. The same verify-as-you-go habit applies to any production work, whether that is a headless WordPress and Next.js build or an automation that archives client sites every month.
A checklist to run this week
A full audit is not required to catch the big ones. Work through this in order:
- Install pending updates. Start here. It is one command and it closes known holes.
- List every service listening on a public port, then switch off anything you cannot name a use for.
- Read your firewall rules line by line and delete rules for software you no longer run.
- Harden SSH: disable root login, move to key-based authentication, and turn password login off.
- Enable two-factor authentication on every control panel, and actually enrol your account rather than only switching the option on.
- Review intrusion detection settings. Default ban times are usually far too short and alert addresses usually go nowhere.
- Replace self-signed certificates with a free trusted certificate.
Do them one at a time. Verify each with a fresh page load or a connection test before starting the next.
The honest conclusion
A clean audit result is not the point. Most of these servers have never been attacked, and that is precisely why the gaps survive. Every one of them is waiting quietly for a bad day that has not arrived yet.
If you host client sites on a VPS you set up yourself, block out two hours this month and go looking. You will find something. If you would rather someone else did the looking, see what I work on or get in touch and tell me what you are running.
Frequently asked questions
Which VPS security fix should I do first?
Install pending operating system and control panel updates first. It is usually one command and it closes known holes. After that, list every service listening on a public port and switch off anything you cannot name a use for, then work through firewall rules, SSH, two-factor authentication, intrusion detection and certificates.
How do I stop SSH on my VPS accepting root password logins?
Check whether root login is permitted and whether password authentication is still on, since that pairing lets anyone on the internet guess the root password all day. Disable root login, switch to key-based authentication and turn password login off. Verify with a fresh connection test before you close your current session.
Why do firewall rules matter if the software behind them isn't running?
Installers tend to open ports generously. A typical audit finds FTP ports open with no FTP server running, including a passive range that can cover more than sixteen thousand ports, plus local network discovery services on a public server and a block of a hundred panel ports when only one is used. Rules guarding nothing still widen what an attacker can probe, so delete the ones for software you no longer run.
Why should I audit a server before changing anything?
The instinct on spotting an open port is to close it immediately, and that is how people lock themselves out of their own server late at night. Read everything first, write down what you find, then decide the order of the work. Changes made along the way also make it harder to know which one caused a problem.
How can one hacked WordPress site affect everything else on a VPS?
Hosting panels commonly give every site account a full login shell. If one WordPress install is hacked, the attacker gets a foothold on the whole machine rather than a single site directory, which puts every other site on that VPS at risk too. When those sites belong to clients, a defacement or data leak becomes their problem as well.