Server Security Best Practices for VPS and Dedicated Hosting

Server security is a small number of settings applied consistently, not a product you buy. Key-only SSH, a default-deny firewall, automatic security updates, least-privilege services and tested backups cover the overwhelming majority of real-world compromises. This checklist applies identically to a €4 VPS and a €209 dedicated server — the hardware tier changes nothing about the attack surface.

The first thirty minutes on a new server

Do these before the machine serves anything. An unhardened server on a public IP starts receiving automated login attempts within minutes of the address becoming reachable.

1. Create a non-root user with sudo

adduser deploy
usermod -aG sudo deploy        # Debian/Ubuntu
usermod -aG wheel deploy       # RHEL family
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

2. Switch SSH to keys only

# on your machine
ssh-keygen -t ed25519 -C "deploy@$(hostname)"
ssh-copy-id [email protected]

Then in /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
AllowUsers deploy

sudo sshd -t && sudo systemctl reload sshd

Keep your current session open and prove the new configuration in a second terminal before closing it. sshd -t catches syntax errors; it does not catch you having no working key.

Ed25519 over RSA: shorter, faster, and no key-size decision to get wrong. Moving SSH to a non-standard port is not security, but it does remove most of the automated noise from your logs, which makes real events visible.

3. Default-deny firewall

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable

Full walkthrough including firewalld, IPv6 and the lock-yourself-out protections: setting up a firewall on your VPS.

4. Automatic security updates

# Debian / Ubuntu
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# RHEL family
sudo dnf install -y dnf-automatic
sudo sed -i 's/^apply_updates.*/apply_updates = yes/' /etc/dnf/automatic.conf
sudo systemctl enable --now dnf-automatic.timer

Restrict automation to the security repository, not every package. Unattended feature upgrades are how a working server becomes a broken one at 03:00. Kernel updates still need a reboot — install needrestart so you know when one is pending.

5. fail2ban

sudo apt install -y fail2ban
printf '[sshd]\nenabled = true\nbantime = 1h\nmaxretry = 5\nbackend = systemd\n' | \
  sudo tee /etc/fail2ban/jail.local
sudo systemctl enable --now fail2ban

Reduce the attack surface

Every listening service is a way in. Find them:

sudo ss -lntup

Anything bound to 0.0.0.0 or [::] is publicly reachable. Databases, Redis, Memcached, Elasticsearch, monitoring agents and admin interfaces should bind to 127.0.0.1. An exposed Redis with no password is compromised in hours; an exposed Elasticsearch is how data leaks make the news. The firewall is a second line of defence and should never be the only one.

Then remove what you are not using:

systemctl list-units --type=service --state=running

Default images commonly ship a mail transfer agent, a print server and snapd. Fewer services means fewer CVEs that apply to you.

Least privilege, applied

• Run applications as their own unprivileged user, never as root. A compromised process should not own the machine.
• Give database accounts only the rights they need. An application that never runs DDL does not need ALTER.
• Use systemd sandboxing. ProtectSystem=strict, PrivateTmp=true, NoNewPrivileges=true and ProtectHome=true in a unit file cost nothing and constrain a compromised service considerably.
• Do not share credentials between environments. A staging leak should not be a production incident.

TLS, done properly

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
sudo certbot renew --dry-run

Then restrict to modern protocols — ssl_protocols TLSv1.2 TLSv1.3; — and verify the renewal timer exists rather than assuming it. Expired certificates are one of the most common self-inflicted outages, and they always happen on a weekend.

Logging and detection

You cannot respond to what you cannot see.

# file integrity baseline
sudo apt install -y aide
sudo aideinit

# audit successful and failed logins
sudo lastlog | grep -v 'Never logged in'
sudo journalctl -u ssh --since "24 hours ago" | grep -i accepted

Ship logs off the machine. An attacker with root deletes local logs first, and a log that only exists on the compromised host tells you nothing about the compromise.

Backups are a security control

Ransomware and a fat-fingered DROP TABLE have the same remedy. Three rules that matter more than the tooling:

• Off the machine. A backup on the server it protects is not a backup.
• Write-restricted credentials. If the server can delete its own backups, so can whoever compromises it. Append-only or write-once storage defeats this entirely.
• Restore-tested. An untested backup is a hypothesis. Restore one on a throwaway instance quarterly — with hourly billing that test costs a few cents.

Automating VPS backups covers a routine that runs without you remembering it.

What is your provider's job and what is yours

Layer	Owner
Physical security, power, network	Provider
Hypervisor and host patching	Provider
Network-level DDoS scrubbing	Provider
Guest OS patching, SSH, firewall	You
Application code and dependencies	You
Backups and their restoration	You

On an unmanaged VPS or dedicated server, everything from the operating system upwards is yours. That is the trade-off you accepted in exchange for root — managed versus unmanaged hosting covers what changes if you would rather not own it.

Frequently asked questions

Is a dedicated server more secure than a VPS?

Not by default. Single tenancy removes one class of theoretical risk, but the operating system, the services and the application are identical. A well-configured VPS is far safer than a neglected dedicated server.

Should I change the SSH port?

It stops automated scanners, not a targeted attacker. Worth doing for log clarity; not a substitute for key-only authentication.

Do I need antivirus on a Linux server?

Rarely. ClamAV is useful if you accept file uploads that will reach Windows users. For server protection itself, file integrity monitoring and reducing the attack surface do far more.

How often should I patch?

Security updates automatically and continuously; everything else on a schedule you control, after testing. The gap between disclosure and mass exploitation is now routinely measured in days.

What do I do if I think I am compromised?

Do not clean and continue. Snapshot for forensics, rebuild from a known-good image, rotate every credential the machine held, and restore data selectively. Rebuilding is cheap; being uncertain is not.

The short version

Keys not passwords, deny by default, patch automatically, listen on as little as possible, run as the least privileged user that works, and test your restores. Applied consistently, that list closes the routes almost every real compromise uses. Every step runs unchanged on a voxa.host KVM VPS or dedicated server, both with full root access and network-level DDoS protection in front.