← Back to Blog

VPS Security · 20 min read · June 29, 2026

The Complete Guide to VPS Security in 2026

Your virtual private server is the backbone of your online presence. But every day, automated bots and targeted attackers probe it for weaknesses. This guide covers everything you need to secure a VPS in 2026 — from initial SSH hardening to real-time AI-powered monitoring.

1. SSH Hardening — Your First Line of Defense

SSH is the most attacked service on any VPS. Automated bots constantly scan for port 22, attempting default credentials and known vulnerabilities. Here is how to lock it down.

Disable root login over SSH

# Create a non-root user with sudo access
adduser yourname
usermod -aG sudo yourname

# Edit SSH config
sudo nano /etc/ssh/sshd_config

# Set these values:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM no

# Restart SSH
sudo systemctl restart sshd

After this change, root cannot log in directly via SSH. Always use your personal user account and escalate privileges with sudo. This single change blocks automated brute-force attacks against the root account.

Set up SSH key-based authentication

# On your local machine, generate a key pair
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/vps_key

# Copy the public key to your VPS
ssh-copy-id -i ~/.ssh/vps_key.pub yourname@your-vps-ip

# Test that key-based login works
ssh -i ~/.ssh/vps_key yourname@your-vps-ip

# Then disable password authentication (already set above)

Ed25519 keys are faster and more secure than RSA. The -a 100 flag increases the number of KDF rounds, making it harder to brute-force the private key if it is ever stolen.

Change the default SSH port

Changing port 22 to a high-numbered port (2222, 8022, or similar) eliminates 99% of automated SSH scanning traffic. This is not real security — a determined attacker will find your port — but it dramatically reduces log noise and resource waste from bot traffic.

sudo nano /etc/ssh/sshd_config
# Change:
Port 22
# To:
Port 2222

# Update firewall rules
sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp

# Restart SSH
sudo systemctl restart sshd

Remember to specify your custom port when connecting: ssh -p 2222 yourname@your-vps-ip. Also update your SSH client config for convenience.

Install and configure fail2ban

sudo apt install fail2ban -y

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

# Set these values:
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3

[sshd]
enabled = true
port = 2222
logpath = %(sshd_log)s
maxretry = 3

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Fail2ban scans log files for repeated failed authentication attempts and temporarily bans the offending IP using the system firewall. With the configuration above, three failed SSH attempts within 10 minutes earns a 1-hour ban.

2. Firewall Configuration

A properly configured firewall is essential. UFW (Uncomplicated Firewall) provides a simple interface to iptables and is pre-installed on most Ubuntu VPS images.

# Set default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow essential services
sudo ufw allow 2222/tcp    # SSH (your custom port)
sudo ufw allow 80/tcp       # HTTP
sudo ufw allow 443/tcp      # HTTPS

# Enable the firewall
sudo ufw enable
sudo ufw status verbose

Additional UFW rules for advanced scenarios

# Rate-limit SSH connections
sudo ufw limit 2222/tcp

# Allow specific IPs only for admin panels
sudo ufw allow from 203.0.113.50 to any port 8080 proto tcp

# Block known bad IP ranges
sudo ufw deny from 10.0.0.0/8

# Log blocked packets for analysis
sudo ufw logging on

The limit rule is especially useful — it allows only 20 connections per 30 seconds from a single IP, after which the connection is denied. This provides a lightweight alternative to fail2ban for SSH rate limiting.

Cloud firewall (provider-level)

In addition to the OS-level firewall, use your VPS provider's cloud firewall panel. Most providers (DigitalOcean, Linode, Vultr, AWS) allow you to define firewall rules at the network level, before traffic even reaches your server. This provides defense in depth: even if your OS firewall is accidentally disabled, the cloud firewall still blocks unwanted traffic.

3. Automatic Security Updates

Unpatched vulnerabilities are the leading cause of VPS compromises. Attackers weaponise CVEs within hours of public disclosure, and automated exploit tools target unpatched systems at scale.

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

# Verify configuration
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

# Ensure these lines are uncommented:
"${distro_id}:${distro_codename}-security";
// "${distro_id}:${distro_codename}-updates";

# Enable automatic reboot for kernel updates
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

# On RHEL/CentOS/Fedora
sudo dnf install dnf-automatic -y
sudo systemctl enable --now dnf-automatic.timer
sudo nano /etc/dnf/automatic.conf

# Set:
apply_updates = yes
reboot = when-needed
reboot_command = "shutdown -r +5 'Applying kernel update'"

4. Intrusion Detection and Malware Scanning

Even with perfect hardening, no system is invulnerable. You need tools that detect the moment an attacker gains access.

Install ClamAV for malware scanning

sudo apt install clamav clamav-daemon -y
sudo freshclam  # Update virus definitions
sudo systemctl stop clamav-freshclam
sudo freshclam
sudo systemctl start clamav-freshclam

# Scan critical directories
sudo clamscan -r --bell -i /etc /bin /sbin /usr /var/www 2>/dev/null

ClamAV detects known malware, trojans, and rootkits by signature matching. Schedule a daily scan with cron and have results emailed to you. Note that ClamAV only catches known threats — it will not detect zero-day malware or custom backdoors.

Install rootkit hunters

# rkhunter
sudo apt install rkhunter -y
sudo rkhunter --check --skip-keypress

# chkrootkit
sudo apt install chkrootkit -y
sudo chkrootkit

Rootkit hunters check for known rootkit signatures, hidden processes, and system file modifications. Run them weekly as part of your maintenance routine. Neither tool provides real-time protection — they are point-in-time scans.

Monitor system logs centrally

# Install auditd for detailed system call monitoring
sudo apt install auditd -y
sudo systemctl enable --now auditd

# Watch for file changes in critical directories
sudo auditctl -w /etc/passwd -p wa -k identity
sudo auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config
sudo auditctl -w /bin -p wa -k binaries

# Review audit logs
sudo ausearch -k identity --start today

The Linux audit framework (auditd) monitors file access, system calls, and security events at the kernel level. Unlike user-space tools, it cannot be subverted by a rootkit that hooks common system commands.

5. Real-Time Monitoring with RootCrak

Periodic scans and manual checks have a fundamental flaw: they only detect threats at the moment you run them. An attacker could compromise your VPS seconds after your nightly scan, have free rein for 24 hours, and exfiltrate all your data before the next scan runs.

RootCrak's AI Watchdog agent runs continuously on your VPS, monitoring:

• Process behaviour — Detects unexpected process spawns, cryptominers, and reverse shells within seconds of execution.
• Network connections — Flags outbound connections to known malicious IPs, command-and-control servers, and unusual geographic destinations.
• File integrity — Monitors critical system binaries and configuration files for unauthorised changes.
• User activity — Alerts on new user accounts, privilege escalation, and suspicious login patterns.
• Vulnerability scanning — Regularly scans open ports and running services for known CVEs.

# Deploy the RootCrak agent on your VPS
curl -sSL https://rootcrak.com/install.sh | bash

# The agent runs as a lightweight systemd service
systemctl status rootcrak-agent

# Check your security dashboard at:
# https://rootcrak.com/dashboard

6. Web Application Security

If your VPS hosts web applications, they represent a significant attack surface. Web apps are the most common entry point for server compromises.

Install a Web Application Firewall (WAF)

# Using Nginx with ModSecurity
sudo apt install libmodsecurity3 nginx -y

# Enable ModSecurity for your site
sudo nano /etc/nginx/sites-available/your-site

# Add inside server block:
modsecurity on;
modsecurity_rules_file /etc/nginx/modsecurity.conf;

sudo nginx -t
sudo systemctl reload nginx

A WAF filters HTTP traffic before it reaches your application, blocking SQL injection, cross-site scripting (XSS), and remote file inclusion attempts. For a full deep dive, read our article on what is a web application firewall and whether you need one.

Run periodic DAST scans

Dynamic Application Security Testing (DAST) probes your running web application for vulnerabilities the same way an attacker would. OWASP ZAP, the industry standard open-source DAST tool, can be run against your own sites to find issues before attackers do.

7. Backup and Recovery Strategy

Security is not just about prevention — it is also about recovery. A solid backup strategy ensures that even if your VPS is compromised, you can restore operations quickly.

# Automate daily backups with rsync
#!/bin/bash
# Save as /usr/local/bin/backup.sh
BACKUP_DIR="/backup/$(date +%Y-%m-%d)"
mkdir -p "$BACKUP_DIR"

# Backup critical configs
cp -r /etc/ssh "$BACKUP_DIR/"
cp -r /etc/nginx "$BACKUP_DIR/"
cp -r /etc/letsencrypt "$BACKUP_DIR/"

# Backup databases
mysqldump --all-databases > "$BACKUP_DIR/mysql.sql"

# Backup application data
rsync -av /var/www "$BACKUP_DIR/"

# Sync to off-site storage
rsync -avz "$BACKUP_DIR/" user@offsite-backup:/backups/vps/

# Keep 30 days of backups
find /backup -mindepth 1 -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \\;

8. Monitoring and Alerting

Without monitoring, you are flying blind. Even the best security configuration is useless if you do not know when something goes wrong.

Set up system resource monitoring

# Install netdata for real-time metrics
bash <(curl -Ss https://my-netdata.io/kickstart.sh)

# Netdata provides a web dashboard at http://your-vps:19999
# of CPU, memory, disk, network, and process metrics

Configure log shipping

# Ship logs to a central location using rsyslog
sudo nano /etc/rsyslog.conf

# Add to forward auth logs
auth.* @log-collector.yourcompany.com:514

sudo systemctl restart rsyslog

Centralised logging ensures that even if an attacker clears logs on your compromised VPS, you still have a record of what happened. This is critical for forensic analysis and incident response.

The Bottom Line

Securing a VPS in 2026 requires a layered approach. The fundamentals — SSH hardening, firewalls, automatic updates, and fail2ban — eliminate the vast majority of automated attacks. Intrusion detection tools and periodic scans catch what the basics miss. And real-time AI-powered monitoring closes the final gap: the time between compromise and detection.

Here is the priority order for a new VPS:

1. SSH hardening — Key-based auth, disable root login, change port, fail2ban.
2. Firewall — Block everything except essential ports.
3. Automatic updates — Patch vulnerabilities within 24 hours.
4. Intrusion detection — ClamAV, rkhunter, auditd.
5. Real-time monitoring — RootCrak agent for continuous protection.
6. Backups — Automated, encrypted, off-site.

Each layer builds on the one before it. Skip a layer, and you create a gap that attackers will eventually find. Follow this guide step by step, and your VPS will be secure against 99% of attacks in 2026.