To secure a VPS you need at least three layers: a firewall that blocks unnecessary ports, a hardened SSH configuration, and regular operating system updates. These three measures alone eliminate the vast majority of automated attacks.
A poorly configured VPS can be compromised within minutes—bots continuously scan the internet for weak credentials and open ports. This guide shows you how to close those doors systematically. You can also find more resources in our VPS servers section.
Why VPS Security Is Your Responsibility
Unlike shared hosting—where the provider manages the server—on a VPS (unless it's fully managed) you are the administrator. That means firewall configuration, patching, and passwords are your job.
The most common attack vectors against VPS servers are:
- Brute-force attacks on SSH port 22.
- Unnecessarily exposed services (databases, control panels).
- Outdated software with known vulnerabilities.
- Weak or reused passwords.
Step 1: Configure the Firewall (UFW or iptables)
The firewall is your first line of defense. Only the ports you actually need should be open.
Option A: UFW (recommended for Ubuntu/Debian)
UFW (Uncomplicated Firewall) provides a simple interface over iptables:
# Default policy: deny all incoming traffic
sudo ufw default deny incoming
sudo ufw default allow outgoing
# Allow SSH, HTTP, and HTTPS
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# Enable the firewall
sudo ufw enable
sudo ufw status verboseIf you're moving SSH to a non-default port (covered in the next step), update the rule before enabling UFW to avoid locking yourself out.
Option B: firewall-cmd (AlmaLinux / Rocky Linux)
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reloadPorts that should almost never be open to the public
| Port | Service | Recommendation |
|---|---|---|
| 3306 | MySQL / MariaDB | Localhost only or specific IP |
| 5432 | PostgreSQL | Localhost only or specific IP |
| 6379 | Redis | Localhost only |
| 8080, 8443 | Alternative panels | Restrict to admin IP |
Step 2: Harden SSH Access
SSH is the gateway to your server. Secure it properly and you'll eliminate the majority of intrusion attempts.
Change the default port
Edit /etc/ssh/sshd_config and change port 22 to a non-standard one (for example, 2222 or any number between 1024 and 65535):
Port 2222This isn't real security on its own, but it dramatically reduces the noise from bots that scan only port 22.
Disable password authentication, use SSH keys
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin noMake sure you've already uploaded your public key to the server with ssh-copy-id before applying this change. Then restart the service:
sudo systemctl restart sshdGenerate an SSH key pair (on your local machine)
ssh-keygen -t ed25519 -C "my_vps_$(date +%Y-%m-%d)"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@VPS_IPUse the ed25519 algorithm: it's shorter, faster, and more secure than 2048-bit RSA.
Set up Fail2Ban
Fail2Ban monitors logs and automatically bans IPs that accumulate too many failed login attempts:
sudo apt install fail2ban -y
sudo systemctl enable fail2ban --nowThe default configuration already protects SSH. To adjust the threshold, create /etc/fail2ban/jail.local:
[sshd]
enabled = true
maxretry = 5
bantime = 3600Step 3: User Management and Privileges
Never work as root day-to-day. Create a regular user with sudo access:
sudo adduser myuser
sudo usermod -aG sudo myuserCore user management principles:
- One account per person—never share credentials.
- Remove accounts for users who no longer need access.
- Periodically review
/etc/passwdand/etc/sudoers. - Use
sudoonly when necessary; drop out of root/sudo as soon as you're done.
Step 4: Keep the System Updated and Monitor Activity
Automatic security updates
On Ubuntu/Debian, install unattended-upgrades to apply security patches automatically:
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgradesMonitor system logs
Regularly review failed access attempts:
sudo journalctl -u ssh --since "24 hours ago" | grep "Failed"
sudo grep "Accepted" /var/log/auth.logTools like Logwatch or GoAccess send daily email summaries, saving you from having to review logs manually.
Install a rootkit scanner
sudo apt install rkhunter -y
sudo rkhunter --update
sudo rkhunter --checkSchedule a weekly cron scan to detect suspicious changes to system files.
If you're looking for a VPS with a managed security layer included, elenlace.com offers fully managed plans where their technical team applies these configurations for you.
Key takeaways
- Enable the firewall from minute one and close every port you don't use.
- Disable SSH password authentication and always use ed25519 keys.
- Change the SSH port and enable Fail2Ban to reduce bot noise.
- Work with an unprivileged user and reserve
root/sudofor administrative tasks only. - Apply security patches regularly—ideally automatically.
Implementing these measures takes under an hour and makes your VPS a much less attractive target for attackers. For expert help with configuration and security audits, reach out to the team at elenlace.com.
FAQ
UFW or iptables — which is better for securing a VPS?
UFW is an abstraction layer over iptables designed to be easier to use. For most general-purpose VPS deployments, UFW is sufficient and far less prone to configuration mistakes. If you need highly granular rules (NAT, complex port forwarding), iptables gives you more control.
Should I disable root SSH access?
Yes, always. Set PermitRootLogin no in /etc/ssh/sshd_config and use a sudo-enabled user for administrative tasks. Direct root SSH access is one of the most exploited attack vectors.
How do I know if my VPS has already been compromised?
Warning signs include abnormal CPU or RAM usage, unusual network traffic, unknown users in /etc/passwd, strange processes when you run ps aux, and odd entries in authentication logs. Tools like rkhunter and chkrootkit automate much of this detection.
How often should I update the server?
Security patches should be applied as soon as they're available—ideally automatically via unattended-upgrades for critical packages. Major OS version upgrades (e.g., Ubuntu 22.04 to 24.04) are planned more carefully, typically once a year in production environments.
Further reading
Other providers and guides worth comparing:
