Securing your VPS

What this is#

A practical security checklist for your VPS. The service is self-managed, so this part is yours, but none of it is hard, and the payoff is huge: almost every compromised VPS we see was taken by an automated scanner exploiting one of a handful of basics, an exposed database port, a weak password, or software left unpatched. Cover the layers below and you're ahead of virtually all of it.

1. Lock down how you get in#

• Use SSH keys instead of passwords. This is the single best upgrade. With key authentication there's no password to guess, brute-forcing becomes pointless, and you'll never get your own IP banned for typos (see the SSH firewall). Save your key on the SSH Keys page and select it when you deploy or reinstall, or add it to ~/.ssh/authorized_keys on a running VPS, the full generate-and-deploy walkthrough is Setting up SSH keys, properly.
• Then disable password login. Once you've confirmed key login works, set PasswordAuthentication no in /etc/ssh/sshd_config and restart SSH. Test the key login in a second terminal before closing your working session.
• Keep the root password strong anyway. You'll still need it for the Console. Long beats clever: several random words together (HolyConcreteThrone style) is both strong and typeable. Use a password manager, or our password generator. Skip the classics that crackers try first: dictionary words with @123 bolted on, keyboard walks like qwerty, names, and "clever" substitutions like D00R8377.
• Never reuse passwords between your VPS, your client account, and anything else.
• Want a second factor on SSH itself? Authenticator-app codes at login are a real option, most valuable if you keep password auth, belt-and-braces on top of keys, the TOTP setup guide covers it, lockout-safe.
• Your VPSDime account already has two-factor authentication on, every account does, with email login codes by default. Upgrading to an authenticator app makes the second factor independent of your mailbox. Whoever controls the account controls the server.

2. Don't expose services to the internet#

The most common VPS compromise isn't SSH at all. It's an application port accidentally open to the whole internet: a database with a weak password, Redis without auth, a Docker API on tcp/2375, an admin panel bound to 0.0.0.0. Scanners find these within hours.

• Bind internal services to 127.0.0.1. If only the VPS itself needs your database or cache, it should listen on localhost, then nothing outside can reach it no matter what.
• Keep our managed firewall on. Linux VPS include a network-edge firewall that blocks the most-attacked app ports by default and lets you whitelist just the sources that need access. It exists precisely for this failure mode. Leave it on.
• Run your own firewall inside the VPS too. Default-deny inbound with only what you serve open (ufw default deny incoming, then allow 22, 80, 443 and whatever you actually run). Two independent layers means one mistake isn't fatal.
• Audit what's listening now and then: ss -tulnp shows every port. Anything LISTENing on 0.0.0.0 or a public address should be something you deliberately serve to the world.

Service-by-service bind instructions (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch, Memcached, Docker's port-publishing trap) live in their own guide: Securing publicly accessible services.

3. Stay updated, and move fast on CVEs#

Unpatched software is the other big door in.

• Update the OS regularly, and put security patches on autopilot: unattended-upgrades on Debian/Ubuntu, dnf-automatic on RHEL-family. A VPS that patches itself at 4am beats one waiting for you to remember.
• The application layer counts just as much. CMSes and their plugins (WordPress especially), panels, Docker images, and app dependencies are attacked more than the OS. Update them on a schedule, and delete plugins and software you don't use, every installed package is attack surface.
• Follow security news for the stack you run. Subscribe to your distro's security announcements, watch the GitHub releases of the software you depend on, and skim a feed like CISA's Known Exploited Vulnerabilities list. The point is speed: when a critical CVE lands in something internet-facing that you run, patching the same day is what separates a non-event from a rebuild. When a scary CVE headline does land, asking an AI chatbot what it means for your stack, and whether your configuration is even exposed, gets you a clear answer in minutes instead of an afternoon of advisory-parsing.

4. Application hygiene#

• Don't live as root. Create a regular user with sudo for day-to-day work; use root only when needed.
• Strong, unique credentials for every service, including ones bound to localhost. A leaked app config shouldn't hand out a password that works elsewhere.
• Protect admin panels. Anything with a login page facing the internet deserves a strong password at minimum, and ideally an IP allowlist or a VPN in front.
• fail2ban is worth installing for exposed login surfaces beyond SSH (mail, panels, WordPress logins). Our network already stops SSH brute-force on port 22, network-wide, and better than a local tool could, but defense in depth is the theme here.

5. Notice trouble early#

• Glance at your Graphs: CPU or traffic that's suddenly pinned when you changed nothing is the classic symptom of a compromise or abuse.
• Check auth logs occasionally (journalctl -u ssh, lastb), and be suspicious of processes you don't recognize.

6. Backups are a security control#

Ransomware, a wiped disk, or a rootkit you can't trust your way out of, all of them end the same way: you restore. Have real, off-site, tested backups. See Backing up your VPS.

If you're compromised anyway#

We suspend compromised VPSes to protect the network, and then you decide: clean it or rebuild it. Our honest advice is rebuild: once a box is rooted you can't fully trust it. Recover data from backups, reinstall, patch whatever let them in, and rotate every credential that lived on the server. The full procedure, including why modern attack bots make in-place cleanup a losing game, is in My VPS was hacked. Recovery, step by step.

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP,
• what you're trying to secure or what you think happened.

Related questions#

• "How do I secure my VPS?"
• "How do I set up SSH keys and disable password login?"
• "How do I choose a strong root password?"
• "Should my database port be open to the internet?"
• "How do I keep my VPS updated automatically?"
• "How do I find out about security vulnerabilities in my software?"
• "What should I do if my VPS was hacked?"