Securing a VPS is not optional — it is a fundamental responsibility that begins the moment your server goes online. A default VPS installation is inherently vulnerable. Within minutes of deployment, automated bots will discover your server's IP address and begin probing it for weak passwords, known exploits, and open ports. Without proper security measures, it is not a question of whether your server will be compromised, but when.
This guide covers the ten most critical security practices that every VPS owner should implement immediately after deployment. These practices are applicable to any Linux-based VPS, regardless of your provider or distribution. We will walk through each one with clear explanations and practical commands you can use today.
Important: Always test security changes in a staging environment first. Incorrect firewall rules or SSH configuration can lock you out of your own server permanently.
1. Secure SSH Access
SSH is the primary gateway to your server, and it is also the most targeted attack surface. Default SSH configurations are designed for convenience, not security. Here are the essential hardening steps:
Disable Root Login
The root user has unlimited privileges, making it the most valuable target for attackers. By disabling direct root login, you force attackers to guess both a username and a password, dramatically increasing the difficulty of brute-force attacks.
sudo nano /etc/ssh/sshd_config
# Find and change these lines:
PermitRootLogin no
PasswordAuthentication no
# Restart SSH to apply changes
sudo systemctl restart sshd
Use SSH Key Authentication
Password-based authentication is vulnerable to brute-force attacks. SSH key authentication uses cryptographic key pairs that are virtually impossible to guess. Generate a key pair on your local machine and copy the public key to your server:
ssh-keygen -t ed25519 -C "your_email@example.com"
# Copy the public key to your server
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server-ip
Change the Default SSH Port
While security through obscurity is not a substitute for real security, changing the default SSH port from 22 to a non-standard port (e.g., 2222 or 49152) eliminates the vast majority of automated scanning bots, significantly reducing login noise in your logs.
Port 49152
# Remember to update your firewall before restarting SSH!
sudo ufw allow 49152/tcp
sudo systemctl restart sshd
2. Configure a Firewall
A firewall is your first line of defense against unauthorized network access. It controls which ports are open to the internet and which are blocked. On Ubuntu/Debian, UFW (Uncomplicated Firewall) is the simplest option. On CentOS/RHEL, firewalld is the default.
Basic UFW Configuration
sudo ufw default deny incoming
sudo ufw default allow outgoing
# Allow SSH (adjust port if changed)
sudo ufw allow 49152/tcp
# Allow HTTP and HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# Enable the firewall
sudo ufw enable
# Verify active rules
sudo ufw status verbose
Cloud-Level Firewalls
In addition to your OS-level firewall, most VPS providers offer a cloud firewall (security groups) that filters traffic before it reaches your server. This is an important secondary layer of defense — even if your OS-level firewall is misconfigured, the cloud firewall will still block unauthorized traffic. Use both layers together for defense in depth.
3. Keep Your System Updated
Unpatched software is one of the most common vectors for server compromise. Vulnerabilities are discovered regularly in the Linux kernel, web servers, databases, and system libraries. Applying security patches promptly is non-negotiable.
Enable Automatic Security Updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# On CentOS/RHEL: install dnf-automatic
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer
Automatic security updates ensure that critical patches are applied within hours of release, even if you are not actively monitoring the server. For production environments, consider testing updates on a staging server first, then pushing them to production with a short delay.
4. Install and Configure Fail2Ban
Fail2Ban monitors log files for patterns of malicious behavior — such as repeated failed login attempts — and automatically blocks the offending IP addresses using firewall rules. It is one of the most effective tools against brute-force attacks.
sudo apt install fail2ban
# Create a local configuration file
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
# Edit /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 49152
filter = sshd
maxretry = 3
bantime = 3600
findtime = 600
# Start and enable Fail2Ban
sudo systemctl enable --now fail2ban
With this configuration, any IP address that fails SSH authentication three times within 10 minutes will be banned for one hour. For persistent attackers, you can increase bantime to 86400 (24 hours) or even -1 (permanent ban).
5. Use Non-Root Users with Sudo
Running services and performing administrative tasks as root is dangerous. A single misconfigured script or compromised application running as root can destroy your entire system. Instead, create a dedicated non-root user with sudo privileges:
sudo adduser deployer
# Add the user to the sudo group
sudo usermod -aG sudo deployer
# Switch to the new user
su - deployer
Use this non-root user for all SSH access and daily operations. Reserve root for emergency situations only. Always use sudo when administrative privileges are needed — this creates an audit trail in the system logs, making it easier to trace actions if something goes wrong.
6. Enable Two-Factor Authentication
Even with SSH key authentication, adding a second factor provides an additional layer of security. Google Authenticator is the most commonly used 2FA solution for SSH:
sudo apt install libpam-google-authenticator
# Run the setup as your user (not root)
google-authenticator
# Follow the prompts to configure TOTP
After configuring Google Authenticator, you will need both your SSH key and a time-based one-time password (TOTP) from your authenticator app to log in. This means that even if an attacker somehow obtains your SSH private key, they still cannot access your server without the second factor.
7. Set Up Intrusion Detection and Monitoring
You cannot protect what you cannot see. Monitoring tools give you visibility into what is happening on your server, alerting you to suspicious activity before it becomes a full-blown breach.
AIDE (Advanced Intrusion Detection Environment)
AIDE creates a database of file checksums and periodically verifies that system files have not been modified. If an attacker installs a rootkit or modifies system binaries, AIDE will detect and alert you.
sudo apt install aide
# Initialize the AIDE database
sudo aideinit
# Run a check
sudo aide --check
Log Monitoring with Logwatch
Logwatch generates daily summary reports of your server's log files, highlighting login attempts, system errors, and security-relevant events. It is a lightweight, low-maintenance way to stay informed about your server's activity.
Real-Time Monitoring
For production servers, consider deploying a monitoring stack such as Prometheus + Grafana, Netdata, or a hosted solution like Datadog or New Relic. These tools provide real-time dashboards for CPU, memory, disk, network, and application metrics, with configurable alerts for anomalous behavior.
8. Implement Automated Backups
Backups are your last line of defense. If your server is compromised, encrypted by ransomware, or suffers hardware failure, backups are the only way to recover your data. Follow the 3-2-1 backup rule: keep three copies of your data, on two different storage types, with one copy stored off-site.
Provider-Level Backups
Most VPS providers offer automated backups (usually weekly or daily) for an additional fee of 20% of your plan cost. Enable these as a baseline — they provide full server snapshots that can be restored with a single click.
Application-Level Backups
In addition to full server backups, implement application-level backups for databases and critical files. These are more granular and allow faster, more targeted recovery:
pg_dump -U dbuser mydb | gzip > /backups/mydb_$(date +%Y%m%d).sql.gz
# Sync backups to off-site storage (e.g., S3, Backblaze B2)
rclone sync /backups remote:my-backups/$(hostname)/
Test Your Backups
A backup that has never been tested is not a backup — it is a hope. Schedule quarterly backup restoration tests to verify that your data can actually be recovered. Restore a backup to a test server and verify data integrity, application functionality, and completeness.
9. Use SSL/TLS Everywhere
All traffic between your users and your server should be encrypted with TLS (Transport Layer Security). This prevents eavesdropping, man-in-the-middle attacks, and data tampering. In 2026, there is no excuse for serving anything over unencrypted HTTP.
Free SSL with Let's Encrypt
Let's Encrypt provides free, automated SSL certificates that are trusted by all major browsers. Certbot automates the process of obtaining and renewing certificates:
sudo apt install certbot python3-certbot-nginx
# Obtain and install a certificate
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
# Certbot automatically sets up renewal via systemd timer
sudo certbot renew --dry-run
Enforce HTTPS Redirect
Configure your web server to redirect all HTTP requests to HTTPS automatically. Also set the HSTS (HTTP Strict Transport Security) header to tell browsers to always use HTTPS for your domain, preventing SSL-stripping attacks.
10. Regular Security Audits
Security is not a one-time configuration — it is an ongoing process. Schedule regular security audits to identify new vulnerabilities, verify that your hardening measures are still in place, and adapt to emerging threats.
Automated Vulnerability Scanning
Tools like Lynis and OpenVAS can scan your server for known vulnerabilities, misconfigurations, and compliance issues:
sudo apt install lynis
sudo lynis audit system
# Review the report for actionable recommendations
Port Scanning
Periodically scan your own server from an external network to verify that only the intended ports are open:
nmap -sV -p 1-65535 your-server-ip
Security Audit Checklist
Run through this checklist at least monthly:
- Verify that all system packages are up to date
- Check that no unauthorized user accounts have been created
- Review SSH login logs for suspicious patterns
- Confirm that firewall rules match your intended configuration
- Validate that SSL certificates are current and properly configured
- Test backup restoration to verify data integrity
- Check for unauthorized cron jobs or scheduled tasks
- Review running processes for unexpected services
- Verify that Fail2Ban is running and banning attackers
- Scan for rootkits using rkhunter or chkrootkit
Server security is a continuous process, not a destination. New vulnerabilities are discovered every week, and your security posture must evolve accordingly. Treat these ten practices as your baseline — the minimum acceptable standard — and build from there.
By implementing these ten security practices, you dramatically reduce the attack surface of your VPS and make it far more resilient against both automated and targeted attacks. Remember: a properly secured VPS running on a modest plan will always outperform a powerful but unprotected server. Security is not an afterthought — it is the foundation that everything else is built on.