Account & Security

Hardening your VPS

A practical baseline of post-deploy security work — SSH, firewalls, brute-force protection, updates, and attack surface reduction.

5 min read

Lite hands you a clean VM with sensible defaults — password SSH disabled, key auth required, OS images patched at build time. Beyond that, hardening the running system is your responsibility. The list below is the baseline we recommend before pointing real traffic at a new instance.

1. Tighten SSH

  • Keep password authentication disabled. The default is correct — do not turn it back on.
  • Create a non-root sudo user for day-to-day work and disable direct root SSH (PermitRootLogin no in /etc/ssh/sshd_config).
  • Restrict who can SSH at the network layer using a Lite firewall (see the next item) rather than relying on SSH alone.
# Add a non-root sudo user, then disable root SSH
adduser deploy && usermod -aG sudo deploy
rsync -a /root/.ssh/ /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl reload ssh

2. Use a Lite firewall as the network gate

A Lite firewall in default-deny mode is the highest-leverage hardening you can apply. Whitelist only the ports you actually serve, and lock SSH to the IP ranges you operate from. The "Protecting your instances with a firewall" guide walks through a sensible starter rule set.

3. Mitigate brute-force and abuse

  • Install fail2ban (or sshguard) to throttle and ban repeated SSH login failures.
  • For HTTP services, enforce rate limits at your reverse proxy (nginx limit_req, Caddy rate_limit) or behind a CDN.
  • Rotate auth and access logs so a compromise does not silently fill up disk.

4. Keep the system patched

  • Run apt update && apt upgrade (or your distro equivalent) on a schedule. Unattended-upgrades is fine for security-only updates.
  • Patch your application runtime (Node, Python, JVM, container images) on the same cadence — not just the OS.
  • Subscribe to the security advisory list for any critical service you run (databases, message brokers, etc.).

5. Minimize attack surface

  • Bind internal services (databases, Redis, internal APIs) to 127.0.0.1 — or, if cross-instance access is needed, use the firewall to only allow specific source IPs.
  • Disable services you do not need. Fewer running daemons means fewer CVEs that affect you.
  • Avoid serving sensitive admin endpoints on the public internet. Reach them via SSH tunnel, VPN, or a Cloudflare-fronted route.

6. Plan for backups

Lite is a compute platform — it gives you a reliable VM, but the data on its disk is yours to back up. For anything important, run periodic off-host backups (S3-compatible object storage, your own infrastructure, third-party backup services) on a schedule. A backup that lives only on the same instance is not a backup.

Tip

These six steps cover the 80% of attacks that hit small VPS deployments. They do not replace a real security audit for production workloads — but they are the price of entry.

Was this guide helpful?

If something is unclear or missing, our team would love to know. Open a ticket and we'll improve this page.

Contact Support