VPS security: a practical checklist for a new server
Internet scanners discover a public VPS within minutes. Protection is a repeatable process: minimum privileges, timely updates, a closed network, independent backups and monitoring.
Define what you are protecting
A static website, VPN gateway and database require different ports, users and recovery targets. Record what data exists, who needs access, which external services the application calls, and how much downtime and data loss are acceptable. For a public site, common risks include password guessing, outdated software, leaked tokens, vulnerable plugins and abusive traffic.
The first hour on a new VPS
| Action | Purpose | Verification |
|---|---|---|
| Update the OS | Close known image vulnerabilities | No critical packages remain |
| Create an administrator | Avoid daily root use | sudo works; direct root login is disabled |
| Add an SSH key | Remove guessable password access | A second session connects with the key |
| Configure firewall | Expose only required services | An external scan sees only allowed ports |
| Enable backups | Create an early recovery point | A test file can be restored |
Keep the current SSH session open while testing the new one. Know how to reach the provider's console or rescue environment before changing network access.
Secure SSH access
Give every administrator a personal key protected by a passphrase. After verifying key login, disable root and password authentication. Moving SSH to another port reduces log noise but is not a security boundary. Restrict source addresses through a firewall or VPN where possible, and create limited non-interactive credentials for automation.
Firewall and minimal attack surface
Deny incoming connections by default and allow only justified ports. Databases, Redis, metrics dashboards and internal APIs should not listen on the public interface. Connect multiple nodes through a private network or WireGuard.
- Map every listening socket to its owner and purpose.
- Remove demo applications and unused control panels.
- Do not publish a Docker port to all interfaces when only containers need it.
- Protect admin panels with additional authentication and IP restrictions.
- Audit IPv6 rules separately from IPv4.
- Understand the provider's DDoS protection limits.
Updates without surprise downtime
The OS, web server, runtime, container base image and application dependencies have separate release cycles. Assign an owner and schedule for each layer. Apply critical fixes quickly; perform normal upgrades during a maintenance window with a backup and rollback path. Pin container versions rather than relying on an unpredictable latest tag.
Permissions, secrets and application security
Run applications under dedicated non-root users and give the database account access only to its schema. Do not put passwords or API tokens in repositories, Dockerfiles, shell history or browser-delivered variables. Use protected runtime secrets and make rotation possible. If a token leaks, revoke it at the issuing service; deleting the latest commit does not remove history.
Use HTTPS with automated renewal, secure cookie flags, input validation and CSRF protection where cookie sessions are used. Log administrative actions without recording passwords, tokens or sensitive personal data.
Detecting and recovering from incidents
Monitor availability, certificate expiry, free disk, CPU, memory, application errors and backup status. Send alerts to a service outside the VPS. Unexpected users, SSH keys, processes, outbound traffic or modified system files can indicate compromise. For a serious incident, isolate the host, rotate external secrets and rebuild from a known configuration rather than trusting an in-place cleanup.
Frequently asked questions
Does a Linux VPS need antivirus?
It can help with mail or uploaded files, but it does not replace updates, least privilege and network controls.
Is changing the SSH port enough?
No. Use keys, disable root and passwords, restrict the network and monitor access.
How often should backups run?
Derive frequency from acceptable data loss. If losing one hour of orders is unacceptable, a daily database copy is insufficient.
Can I stop DDoS attacks with a local firewall?
Not when traffic saturates the upstream link. Provider or proxy mitigation is required, while local rate limits still help against application abuse.
Continue with VPS backup and restore planning.