Five signs your VPS needs an audit

Most VPS audit guides are a checklist of thirty things to configure. Useful if you are building a box from scratch, useless if you already have one running and just want to know whether it is in trouble. So here is the other version: five signs that a server you already own needs a proper look, the kind you can spot without being a sysadmin, and the one-line command to confirm each one. If two or more of these are true, your VPS is overdue.

Sign one: the bandwidth bill went up and your traffic did not

This is the clearest tell and the one owners notice first, usually on an invoice. If your provider’s outbound traffic graph is climbing while your visitor count is flat, something on the box is sending data you did not ask it to. The usual causes are a compromised server relaying spam, taking part in a botnet, or quietly exfiltrating files.

Check the provider’s bandwidth graph first, then look at what is talking on the server itself with iftop or nethogs. If a process you do not recognise is pushing megabits to an address you have never heard of, you have your answer. Legitimate servers are boring; their traffic matches their job.

Sign two: the load is high but the site is quiet

You check top or your panel’s resource graph and the CPU is pinned, but the site has barely any visitors. The single most common reason we find is a crypto miner. Someone got in, dropped a mining binary, and is now renting your CPU to themselves at your electricity and your performance budget. Not every slow box is compromised, mind you — sometimes it is just an untuned database, which is why we tune MariaDB on CyberPanel servers before assuming the worst.

Run top and look at the top process. Miners are not subtle: a process eating 90 percent CPU with a random-looking name, often running out of /tmp or /dev/shm. Cross-check with ls -la /tmp /dev/shm for executables that have no business being there. A quiet site with a hot CPU is not a tuning problem, it is an intrusion until proven otherwise.

Sign three: your auth log is a wall of failed logins

Every internet-facing server gets login attempts; that is background noise. The question is whether anyone is getting through and whether you have made it easy. Open the log and count:

grep "Failed password" /var/log/auth.log | wc -l

A few hundred over a week is normal. Tens of thousands means you are being hammered, and if password login is still enabled for root, you are one weak credential away from a bad week. The fix is not to watch the number, it is to make the attempts pointless: SSH keys only, root login disabled, and fail2ban banning repeat offenders. We treat password-based SSH on a production box as a finding by itself, regardless of what the log says today.

Sign four: there are cron jobs and processes you did not create

When an attacker gets in, the first thing they want is to stay in after a reboot or a cleanup. They do it by adding a scheduled task or a service that re-downloads their payload. So an unfamiliar cron entry is one of the most reliable signs of a real compromise, not just attempted one.

Look in three places: crontab -l for the current user, ls -la /etc/cron.* for system schedules, and systemctl list-units --type=service --state=running for services. You are reading for anything that pulls from a URL, runs out of a temp directory, or has a name that is almost but not quite a real system service. If you find one, do not just delete it. That is the point where you stop poking and get the box properly examined, because something put it there and that something may still have access.

Sign five: the system has not been updated in months

The least dramatic sign and the most common. A VPS that nobody patches is a CVE waiting for a scanner to find it, and scanners find everything. Check how far behind you are:

apt list --upgradable and lsb_release -a on Debian or Ubuntu.

If there are dozens of pending security updates, or the OS version itself is past its end of life and no longer getting patches at all, the box is exposed to vulnerabilities that have public exploit code. An end-of-life OS is the worst case here, because there is no update to apply; the only fix is a migration to a supported release, which is a project rather than a command. This is exactly the situation we walk people through when they move to a properly maintained VPS in the first place.

What an actual audit covers

The five signs tell you something is wrong. An audit tells you how wrong and fixes it. Part of that audit is picking the right WAF, which we break down in our ModSecurity vs Imunify360 comparison. If the server already went down, our server crash post-mortem traces the cause from the logs. When we audit a server we go through SSH and firewall configuration, every running service and open port, the user and sudo list, file integrity on the web root, the update and kernel state, log retention, and backups, because a server you cannot restore is a server you do not really control. You get a written findings list ranked by severity and the remediation done, not just a PDF telling you to do it yourself.

If two or more of the signs above rang true, do not wait for the bandwidth bill to settle the question. A Linux server security audit is a fixed scope that ends with a hardened box and a report you can act on, and it sits inside the broader security work we do across the stack. If you are running a control panel like CyberPanel or cPanel, the same audit applies with the panel’s own surface added on top of the server fundamentals.

If you want the preventive side rather than the audit, our Linux server hardening checklist walks through the same fixes in the order we apply them.

One cheap safeguard between audits is automated server monitoring on a cron job that pings Slack the moment something crosses a threshold. Add an expiry check to it too, because a silent Let’s Encrypt renewal failure is one of the more common ways a healthy-looking box starts throwing browser warnings.

Picking the provider in the first place is its own call. We lay out the trade-offs in Hetzner versus DigitalOcean for a WordPress site, from cost per core to backups.