When you run WordPress on your own VPS, you are responsible for more than WordPress. The server underneath it, its operating system, its login and its open ports, needs looking after too.
That sounds heavier than it is. Most attacks on WordPress servers are automated and opportunistic: bots scanning the whole internet for weak passwords, old software and open doors. A handful of sensible measures closes most of those doors.
1. Log in with SSH keys, not passwords
Bots try to guess SSH passwords around the clock. The simplest defence is to stop accepting passwords at all.
- Create an SSH key pair on your computer and add the public key to the server.
- Confirm you can log in with the key.
- Then turn off password logins in the SSH server’s settings (
PasswordAuthentication no).
Keep your private key safe, and keep a second way in, such as your VPS provider’s web console, in case you lose it.
2. Close every port you do not need
A WordPress server normally needs only three ports open to the world:
- 22 for SSH,
- 80 for HTTP, mostly to redirect to HTTPS and to renew certificates,
- 443 for HTTPS.
Everything else, including the database, should be closed to the outside. Use the server’s firewall, such as ufw or nftables, or your VPS provider’s cloud firewall, or both. The database in particular should only listen on the server itself, never on the public internet.
3. Keep the operating system updated
Security fixes for the operating system, the web server, PHP and the database are released constantly. On Debian and Ubuntu, unattended upgrades can install security updates automatically, which is a sensible default for most servers.
Also keep an eye on the bigger picture:
- run an operating system release that is still supported, such as Debian 13 or Ubuntu 26.04 LTS,
- run a PHP version that still receives security fixes.
4. Keep sites apart from each other
If you host several sites on one server, a hacked plugin on one site should not be able to reach the others. Run each site with its own system user and file permissions, or better, in its own container. Give each site its own database and database user, with access only to its own data.
5. Harden WordPress itself
The server is only half the picture. Inside WordPress:
- Keep core, themes and plugins updated. Outdated plugins are the most common way WordPress sites are compromised. Our guide on updating plugins without breaking your site shows how to do it safely.
- Delete what you do not use. Deactivated plugins and old themes can still be attacked if their files are on the server.
- Use strong, unique passwords and two-factor authentication for every admin account.
- Do not use “admin” as a username, and give users only the role they need.
- Turn off the built-in file editor by adding
define( 'DISALLOW_FILE_EDIT', true );towp-config.php, so a stolen admin login cannot be used to edit PHP files from the dashboard. - Limit login attempts to slow down password guessing on
wp-login.php. - Disable XML-RPC if nothing you use needs it, since it is a popular target for brute-force attempts.
6. Encrypt everything in transit
Every site should have a valid SSL certificate, with HTTP redirected to HTTPS. Admin logins, customer details and payment pages must never travel unencrypted. We covered this in free SSL for WordPress.
7. Have backups you can restore
No checklist makes a server impossible to break into. Backups are what make a break-in survivable.
- Keep backups off the server, so an attacker who gets in cannot delete them too.
- Keep several versions, because a hack can go unnoticed for weeks.
- Test a restore now and then.
See how to back up a WordPress site for the details.
8. Watch for trouble
- Check for unexpected admin users, plugins you did not install, and files that changed when nothing should have.
- Watch disk, CPU and memory. A sudden spike can be a sign of abuse, such as a hacked site sending spam.
- Keep logs, and look at them when something seems wrong.
The short version
- SSH keys only, password login off
- Firewall allowing only SSH, HTTP and HTTPS
- Automatic security updates for the operating system
- Sites isolated from each other
- WordPress, themes and plugins kept updated, unused ones deleted
- Strong passwords, two-factor and no file editor
- SSL on every site
- Off-server backups, tested
Where Rubuz fits
When Rubuz sets up a server, it sets the firewall to allow only SSH, HTTP and HTTPS and turns off SSH password logins. Each site runs in its own containers, with free SSL, safe updates and encrypted backups to storage you own, and Rubuz leaves no agent running on your server. The getting started guide walks through connecting a server.