Hardening a Linux VPS for business applications: the first-week checklist

A new Linux VPS is reachable by the whole internet within minutes of booting, and automated scanners will find it whether or not anyone has linked to it yet. Most sweep every address they can reach, trying default credentials and unpatched services. Hardening is not about making a server impregnable. It is about closing the cheap, automated routes in during the first week, so breaking in requires real effort rather than a lucky guess.

Assume the server is already being probed

Any internet-facing server's authentication log tells the same story: thousands of failed logins from strangers, probing common usernames and weak passwords. That background noise is the reason defaults are dangerous. A server left with password authentication enabled, a root login open, and every port answering is not waiting to be attacked; it is already being tested, continuously, for free.

The response is a short, ordered list: lock the front door first, narrow what the server exposes, then keep it patched and notice when something changes. If you have just moved onto a VPS, this is the natural follow-up to moving a business website from shared hosting to a VPS without downtime — migration gets you onto your own server, and hardening is what makes that server safe to run a business on.

Lock down SSH before anything else

SSH is the most valuable target on the server because it gives full shell access. Three changes remove nearly all automated SSH attacks: disable password authentication, disable direct root login, and use key-based authentication only. With those in place, a password-guessing bot has nothing to guess against.

The change is small:

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
MaxAuthTries 3

Before restarting SSH, test the new configuration from a second session while keeping the first open, so a failed key login leaves you a way back in. Changing the SSH port can reduce log noise, but treat it as tidiness, not security: port scans find it in seconds, and it must never substitute for key-only authentication.

Firewall: deny by default, open only what you use

A firewall rule set should start from deny and add exceptions. On a typical business web server, the public internet needs HTTP and HTTPS, plus SSH from the addresses you actually administer from. Everything else — database ports, control panels, internal services — should not answer to the world at all.

That last point turns a small misconfiguration into a breach. A database listening on its default port and reachable from the internet is an invitation, regardless of how strong its password is. Bind databases and internal services to localhost or a private network, and let the firewall enforce it. The same discipline applies to deploys: a deployment pipeline should prove what it ships, and part of that proof is that it only opens the access it genuinely needs.

Automate updates; do not rely on memory

Most server compromises do not use exotic zero-days. They use known vulnerabilities in software that was never patched, weeks after the fix was published. Manual patching fails because someone gets busy and the update slips by a month; unattended security updates remove that failure mode.

Enable automatic security updates, and schedule a window for the rest: runtimes, web servers, and anything outside the package manager. Then verify the automation is actually running: confirm updates are being applied, that the server still serves after them, and that a failed update would be visible rather than silent. Patching cadence is part of operations, and it belongs in the same routine as the rest of your platform work for a small team.

Users and privileges: small, separate, auditable

Every person and every service on the server should have its own account, with only the permissions its job requires. Shared accounts destroy accountability: when five people log in as the same user, no log can tell you who did what, and revoking one person's access means changing a password everyone shares. Give administrators individual key-authenticated accounts, each application its own unprivileged user, and reserve privilege escalation for explicit, logged use.

The same principle governs files. Application files should not be writable by the web server process, and uploaded content should never be executable — the same separation that makes secure file downloads with signed URLs and expiry safe applies on the server itself: data users can write must not become code the server runs. Review sudo access and stale accounts when someone leaves the team.

Hardening includes recovery

A hardened server still fails — sometimes because of the hardening itself, like a firewall rule that blocks a legitimate service. That is why backups belong in a hardening checklist. They must be automatic, stored off the server, and tested by an actual restore.

The test matters more than the backup job's green status light. A MySQL backup you have actually restored is what turns a bad day into a short one; an untested backup is a hope, not a plan. Schedule a restore test, write down the steps, and keep a copy of the recovery procedure somewhere other than the server it is meant to recover.

Watch the server after you harden it

Hardening without monitoring is a snapshot: true on the day you did it, quietly false a month later when a new service opens a port or an update re-enables a default. At minimum, watch failed SSH logins, firewall denies, disk space, and whether your services are answering. Alerts should go somewhere a human reads them, and be few enough that they are not ignored.

This is the same visibility discipline that observability for asynchronous workflows argues for in application code: background work you cannot see is work you cannot trust. The useful alerts are the quiet ones — a sudden rise in denied connections, or a service that stopped logging — that arrive while there is still time to act.

First-week checklist

• Disable SSH passwords and root login; key-only access, tested from a second session.
• Deny-by-default firewall: HTTP, HTTPS, and SSH only from admin addresses.
• Bind databases and internal services to localhost or a private network.
• Enable unattended security updates and schedule a window for everything else.
• Create one account per person and per service; remove shared logins and stale accounts.
• Make application files unwritable by the web server, and uploaded content non-executable.
• Set up off-server backups and prove them with a real restore test.
• Turn on basic monitoring and alerting for logins, firewall denies, disk, and service health.
• Record every change, so the next person can tell deliberate configuration from drift.

None of this requires expensive tooling, and all of it fits in a first week. The goal is a server where the cheap attacks fail, the remaining risks are visible, and recovery is rehearsed rather than improvised. Do these nine things, and the automated scanners move on to easier targets.

If you would rather have this done once and documented, our cloud, VPS and DevOps work covers server setup, hardening, deployment, and recovery. And if your server is already live and its state is uncertain, talk to us before the next scan finds the gap.