Back to Blog/

Hardening Your VPS: 7 Security Steps Every Server Should Have

A practical hardening checklist for a fresh VPS: SSH key auth, firewall, automatic security updates, and monitoring - the baseline we apply to every EGYmass server.

The seven security steps every VPS should have are: SSH key authentication, a host firewall, automatic security updates, a fail2ban-style brute-force guard, TLS everywhere, daily automated backups, and monitoring that alerts you when something is wrong.

1. SSH key authentication

Password login is the single most attacked service on the internet. Disable password authentication and root login over SSH, and require a key - ideally an ed25519 key protected by a passphrase, generated with ssh-keygen and copied to the server with ssh-copy-id. The rule that saves you from the locked-out story: keep your current session open, edit sshd_config to set PasswordAuthentication no and PermitRootLogin prohibit-password, then connect from a second terminal and confirm the key still works. Only then may you close the first session. Finally, treat the key like a house key: one on your laptop, one offline backup, and a documented recovery path - because a lost key with no fallback means a support ticket and a forced reinstall.

2. A host firewall

Open only the ports a service actually needs - typically SSH, HTTP, and HTTPS - and deny everything else by default: every incoming packet refused unless an explicit rule allows it, outgoing traffic allowed. Apply the same rules to IPv6, which is not a details column - a server that only filters IPv4 stays fully reachable over its second stack. Make the rules persistent so a reboot does not leave the server wide open. The classic trap is enabling a firewall without allowing the SSH port you are connected through: at the first blocked packet you are out, exactly like losing the key - so allow that port first and verify from a second session before you save.

3. Automatic security updates

Enable unattended-upgrades for security patches so a CVE is fixed within hours instead of weeks. The package-level updates are the ones that should never wait for a human; the only part worth scheduling deliberately is a kernel update, which needs a reboot to take effect - pick a maintenance window, or use live patching where the distribution supports it. Two habits make automatic updates safe rather than scary: read the update log regularly so silent failures surface instead of accumulating, and watch the packages that are pinned or held back, because a pinned vulnerable package will not fix itself. Security updates applied a week late are how small servers become part of large botnets.

4. Guard against brute-force attacks

Bots hammer SSH and login pages around the clock. With key-only SSH, brute-forcing the SSH port is already a dead end - which is exactly why the bots moved to the surfaces still open: web logins, admin panels, mail. Run a tool like fail2ban or a comparable rate-limiter that bans repeated failed attempts for long enough to make guessing uneconomical, and let it feed the firewall so bans become real rules instead of log lines. Add rate limiting and a WAF in front of web apps to filter malicious requests before they reach your code. Measure it once a month: if a single IP produced thousands of failed logins yesterday, the guard is doing its job.

5. TLS everywhere

Terminate TLS 1.3 in front of your services - 1.2 as a minimum, never anything older - with strong modern ciphers, and redirect every HTTP request to HTTPS so a mistyped URL cannot hand credentials to the network. Add HSTS once the redirect has been live for a while, and it stops the first-visit downgrade entirely. Manage certificates with an automated ACME client, with renewal checked daily and the expiry date exported to monitoring: a certificate that renews silently can also fail silently, and an expired certificate is the one outage visitors see before any of your dashboards. Renewal should never be a calendar reminder that quietly becomes an incident.

6. Daily automated backups

A backup you have never restored is not a backup - it is a hope. Automate daily snapshots of what actually rebuilds the service: database dumps, configuration files, and user uploads, not just the whole disk. Keep copies off-server and ideally off-site, which is the difference between a hardware failure and a bad morning, and set a retention policy so old backups clean themselves up instead of filling the disk you are monitoring in step seven. Encrypt anything leaving the server. Then prove it: once a quarter, restore into a scratch environment and confirm the service actually comes back - because a backup with a silent corruption will fail on the day you need it, and that is the wrong day to learn that.

7. Monitoring and alerting

You cannot respond to an incident you never hear about. Monitor disk, memory, CPU, and the health of each service, and alert on the trend rather than the binary state: a disk at 85 percent and growing is an alert, while a disk that sits at 85 percent for a year is not. Fold in the things that fail quietly - certificate expiry, backup jobs that stopped running, failed logins spiking, security updates that stopped applying - because those are the incidents you would otherwise find from a customer message. Route alerts to a channel someone actually reads, with an escalation rule for nights and weekends. The goal is to learn a disk is nearly full before it takes the database down with it.

VPSSecurityDevOps

Frequently Asked Questions

In what order should I apply these steps?

SSH keys and firewall first - they are the cheapest and stop the most common attacks - then automatic updates, then fail2ban. TLS, backups, and monitoring can follow, but none should wait longer than a week on an internet-facing server.

Is this enough for production?

It is the baseline. Production also needs a WAF/IDS layer in front, a tested restore procedure, isolated environments, and an access-control policy. These seven steps take a server from default-vulnerable to solid.

Do you apply this to your own servers?

Yes - this is the exact baseline we apply to every EGYmass server, and the stack behind our VPS setup service. The same automation and monitoring keeps our own products online.

Want this set up for you?

EGYmass handles hosting, security, and ongoing management - so you can focus on your product.

Get a Free Consultation