Linux VPS Security: Layers, Threats, Hardening

You just provisioned a Linux VPS. Within 90 seconds, automated scanners have already found it. Within the first hour, your SSH logs will show hundreds of brute-force login attempts from botnets cycling through common usernames and passwords.

This is not hypothetical. It happens to every public-facing server.

Most VPS security guides hand you a numbered list of 20+ tips with no structure or priority. This guide takes a different approach. It maps security as concentric layers, each one reducing your attack surface further. You will understand what attacks actually hit your server and which defenses stop them.

If you are setting up your first VPS, start with the first 5 security steps. That section alone blocks over 90% of automated attacks.

If you are an experienced admin, use the jump links to go straight to the layer you need.

This guide covers Debian 12 and Ubuntu 24.04. All commands are tested on both.

What attacks target a fresh Linux VPS?

A fresh VPS with a public IP faces automated attacks within seconds of going live. Botnets continuously scan the entire IPv4 space. The most common attacks are SSH credential stuffing, port scanning for exposed services, and exploitation of known vulnerabilities in unpatched software.

Understanding the threat model makes every recommendation in this guide click. Here is what actually happens:

Automated scanning

Botnets scan the full IPv4 address range constantly. Projects like Shodan and Censys index every reachable port. Your server is not targeted specifically. It is found because it exists.

Within the first hour of provisioning, expect:

200+ SSH login attempts from distributed IPs
Port scans probing for databases (3306, 5432), web servers (80, 443), and admin panels
Requests for known vulnerable paths (/wp-admin, /phpmyadmin, /.env)

Credential stuffing and brute force

Attackers use leaked credential databases to try username/password combinations against your SSH service. They rotate through root, admin, ubuntu, deploy, and other common names. If password authentication is enabled with a weak password, compromise takes minutes.

Supply chain and post-compromise

Once inside, attackers install cryptominers, add SSH backdoors, or use your server as a relay for further attacks. Some install rootkits that survive reboots. A compromised VPS can be used to attack other servers, which makes you liable for the traffic.

There is also a growing trend of supply chain attacks targeting package repositories and install scripts. The curl | bash pattern, common in many setup guides, executes arbitrary code from the internet without verification. Avoid it. Download scripts, verify checksums, then execute.

Reconnaissance through version disclosure

Attackers fingerprint your server software to find matching exploits. A web server responding with Server: nginx/1.24.0 or an SSH banner revealing the exact OpenSSH version tells an attacker exactly which CVEs to try. Version hiding is a small step, but it removes low-effort targeting. Throughout this guide and the linked tutorials, you will see how to disable version disclosure for each service.

What this means for your defenses

Each layer in this guide addresses specific attack vectors:

Attack Vector	Defense Layer
SSH brute force	SSH key auth, Fail2Ban
Port scanning	Firewall (UFW/nftables)
Credential stuffing	Disable password auth, non-root user
Unpatched vulnerabilities	Automatic security updates
Unauthorized access to admin services	VPN (WireGuard/Tailscale)
Privilege escalation	User permissions, sudo

What are the first 5 security steps on a new VPS?

If you do nothing else, do these five things. They take under 15 minutes and block the vast majority of automated attacks: 1) update all packages, 2) create a non-root user with sudo, 3) configure SSH key authentication and disable passwords, 4) enable a firewall, 5) install Fail2Ban.

Here is the quick-start sequence. Each step links to a detailed tutorial.

1. Update all packages

apt update && apt upgrade -y

This patches known vulnerabilities. On a fresh VPS, the base image may be weeks or months behind on security patches.

2. Create a non-root user

adduser deploy
usermod -aG sudo deploy

Working as root means any mistake or exploit has full system access. A sudo user requires explicit privilege escalation.

3. Set up SSH key authentication

On your local machine, generate an Ed25519 key pair if you don't have one:

ssh-keygen -t ed25519 -C "your-email@example.com"

Copy it to your server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@your-server-ip

Then on the server, edit /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Restart SSH. On Ubuntu 24.04, SSH uses socket-based activation:

# Ubuntu 24.04
sudo systemctl restart ssh.socket

# Debian 12
sudo systemctl restart sshd

Verify before disconnecting: open a second terminal and confirm you can log in with your key as the new user. Never close your current session until you have verified access.

4. Enable a firewall

# Install UFW (pre-installed on Ubuntu, needs install on Debian)
sudo apt install ufw -y

# Allow SSH before enabling
sudo ufw allow ssh

# Enable the firewall
sudo ufw enable

# Verify
sudo ufw status

You should see SSH (port 22) listed as ALLOW. Everything else is denied by default.

5. Install Fail2Ban

sudo apt install fail2ban -y

Create a local jail configuration:

sudo tee /etc/fail2ban/jail.d/sshd.conf > /dev/null << 'EOF'
[sshd]
enabled = true
maxretry = 3
findtime = 600
bantime = 1800
EOF

On Debian 12, Fail2Ban needs to read from journald instead of auth.log:

# Debian 12 only
echo "sshd_backend = systemd" | sudo tee -a /etc/fail2ban/paths-debian.conf

Start and enable the service:

sudo systemctl enable --now fail2ban

Verify it is running:

sudo systemctl status fail2ban
sudo fail2ban-client status sshd

You should see the sshd jail listed as active with 0 currently banned IPs. Within hours, you will start seeing bans.

How does SSH hardening protect your server?

SSH is the front door to your server and the number one target for automated attacks. Hardening SSH means replacing password authentication with cryptographic keys, disabling root login, and limiting which users and algorithms the server accepts. These changes reduce the SSH attack surface from "try any password" to "present this exact private key."

Beyond the basics covered in the first 5 steps, a hardened SSH configuration includes:

Ed25519 keys only. Faster and more secure than RSA. The key is 256 bits but provides 128-bit security, equivalent to RSA-3072.
Idle timeout. Disconnect inactive sessions to prevent abandoned terminals from being hijacked:

ClientAliveInterval 300
ClientAliveCountMax 2

Restrict users. Limit SSH access to specific accounts:

AllowUsers deploy

Disable unused authentication methods:

KbdInteractiveAuthentication no
X11Forwarding no

Hide the SSH version banner. While OpenSSH does not let you fully suppress its protocol version, you can remove custom banners and limit information leakage:

Banner none
DebianBanner no

After any change to sshd_config, validate the syntax before restarting:

sudo sshd -t

If the command produces no output, the configuration is valid. Then restart SSH and verify you can still log in from a second terminal. Always test from a second session. If the config is broken, you still have your existing connection.

For the full SSH hardening walkthrough with tested configs for Debian 12 and Ubuntu 24.04, see .

Why does your VPS need a firewall?

A firewall controls which network traffic reaches your server. Without one, every service you run is exposed to the internet. A database on port 5432, a dev server on port 3000, a Redis instance on port 6379: all reachable by anyone. The firewall ensures only the ports you explicitly open are accessible.

Debian 12 and Ubuntu 24.04 both use nftables as the kernel-level packet filtering framework. UFW (Uncomplicated Firewall) sits on top as a user-friendly interface. For most VPS use cases, UFW is the right choice.

UFW vs nftables: when to use which

	UFW	nftables
Best for	Single-server setups, web apps	Multi-server, advanced routing
Learning curve	Minutes	Hours to days
Default on	Ubuntu (pre-installed)	Debian 12 (backend)
Rule syntax	`ufw allow 443/tcp`	Tables, chains, rule expressions
When to switch	N/A	Need per-packet logging, rate limiting rules, complex NAT

A typical web server firewall setup with UFW:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Verify the rules:

sudo ufw status numbered

Each open port is a potential entry point. Only open what your application needs. If you remove a service, remove its firewall rule too.

For detailed firewall configuration including nftables rules, rate limiting, and port-specific access control, see .

How does Fail2Ban stop brute-force attacks?

Fail2Ban monitors log files (or journald on Debian 12) for repeated failed authentication attempts and temporarily bans the offending IP addresses using firewall rules. It turns a brute-force attack from "try 10,000 passwords" into "try 3 passwords, get blocked for 30 minutes, start over from a different IP."

How it works

Fail2Ban watches SSH authentication logs
After maxretry failures within findtime, it creates a firewall rule blocking that IP
After bantime expires, the rule is removed
Persistent attackers cycle through IPs, but the rate limit makes credential stuffing impractical

Recommended settings for a VPS

The defaults are too lenient for a public-facing server. Here is a production configuration:

sudo tee /etc/fail2ban/jail.d/sshd.conf > /dev/null << 'EOF'
[sshd]
enabled = true
maxretry = 3
findtime = 600
bantime = 3600
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 86400
EOF

This configuration bans an IP for 1 hour after 3 failures. If the same IP comes back, the ban doubles each time, up to 24 hours. This is more effective than a flat ban time because automated scanners will eventually deprioritize your server.

Restart Fail2Ban to apply:

sudo systemctl restart fail2ban

Check active bans:

sudo fail2ban-client status sshd

Watch bans happen in real time:

sudo tail -f /var/log/fail2ban.log

For the full Fail2Ban setup guide covering custom jails for Nginx, Postfix, and other services, see .

How do user permissions reduce your attack surface?

Running services as root gives an attacker full system access if that service is compromised. The principle of least privilege means each process runs with the minimum permissions it needs. A web server compromise should not give access to your database, your SSH keys, or your system configuration.

Key practices

Never run application services as root. Web servers, databases, and application runtimes should each have their own system user:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /opt/myapp myapp

The --system flag creates a user without a home directory login. The --shell /usr/sbin/nologin prevents interactive login. This user can run your application but cannot SSH in or execute arbitrary commands.

Restrict sudo access. Only users in the sudo group should have elevated privileges. Audit who has sudo:

getent group sudo

Set file permissions correctly. Configuration files with passwords or API keys should not be world-readable:

# Restrict a config file to owner only
sudo chmod 600 /etc/myapp/config.env
sudo chown myapp:myapp /etc/myapp/config.env

# Verify
ls -la /etc/myapp/config.env

You should see -rw------- permissions, meaning only the owner can read and write.

Use environment files for secrets. Instead of hardcoding credentials in config files, create a dedicated environment file with restricted permissions:

sudo tee /etc/myapp/env > /dev/null << 'EOF'
DB_PASSWORD=your-generated-password
API_KEY=your-api-key
EOF

sudo chmod 600 /etc/myapp/env
sudo chown myapp:myapp /etc/myapp/env

Reference it in systemd units with EnvironmentFile=/etc/myapp/env. Generate passwords with openssl rand -base64 32 instead of picking them manually.

For the full guide on Linux user management, sudo configuration, and permission models, see .

Why should you automate security updates?

Unpatched software is one of the most exploited attack vectors. When a vulnerability is disclosed, attackers start scanning for unpatched servers within hours. Manual updates mean your server is vulnerable from disclosure until you next remember to run apt upgrade. Automatic security updates close that window.

Setting up unattended-upgrades

Ubuntu 24.04 includes unattended-upgrades in its default server installation, but some VPS providers ship minimal images without it. Debian 12 also requires installation. On either distribution, install it if not already present:

sudo apt install unattended-upgrades apt-listchanges -y
sudo dpkg-reconfigure -plow unattended-upgrades

Verify it is active:

cat /etc/apt/apt.conf.d/20auto-upgrades

You should see:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

The "1" means daily. Package lists update every day, and security patches install automatically.

What gets updated

By default, only security updates from the official repository are installed. This is the right setting for a production server. Feature updates and major version changes still require manual intervention, which prevents unattended upgrades from breaking your application.

Monitoring updates

Check what has been installed automatically:

sudo cat /var/log/unattended-upgrades/unattended-upgrades.log

Set up email notifications for applied updates by editing /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Mail "admin@example.com";
Unattended-Upgrade::MailReport "on-change";

For automatic reboot handling when kernel updates require it:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Only enable automatic reboots if your application handles restarts gracefully. For most setups, a weekly manual check is better than surprise reboots.

For the full setup guide including monitoring and troubleshooting, see .

When should you add VPN access to your VPS?

Add VPN access when you run services that should never be exposed to the public internet: admin panels, databases, monitoring dashboards, or internal APIs. A VPN creates an encrypted tunnel so these services are reachable only from devices on your private network. Instead of opening port 3000 to the world and hoping your authentication holds, you close it from the internet entirely and access it through the VPN.

WireGuard vs Tailscale

	WireGuard	Tailscale
Setup time	15-30 minutes per peer	2-5 minutes total
Configuration	Manual key exchange, config files	SSO login, automatic
NAT traversal	Manual port forwarding	Automatic
Control	Full, you manage everything	Coordination server is third-party
Cost	Free, self-hosted	Free up to 100 devices
Best for	Fixed infrastructure, full control	Teams, dynamic devices, quick setup

Choose WireGuard when you want full control over your network, have static infrastructure, and are comfortable managing key pairs and config files.

Choose Tailscale when you need quick setup across multiple devices, work with a team, or want automatic NAT traversal without port forwarding.

Both use the WireGuard protocol underneath. Tailscale is WireGuard with orchestration.

What to put behind VPN

Database ports (PostgreSQL 5432, MySQL 3306, Redis 6379)
Admin panels (phpMyAdmin, Adminer, Grafana)
Monitoring endpoints (Prometheus, Node Exporter)
Internal APIs not meant for public consumption
SSH access (belt and suspenders: key auth + VPN)

A common pattern: keep ports 80 and 443 open for your public web application. Everything else goes through the VPN. Your firewall rules become:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 51820/udp  # WireGuard
# SSH only from VPN subnet
sudo ufw allow from 10.0.0.0/24 to any port 22

For step-by-step setup of both WireGuard and Tailscale on your VPS, see .

What about changing the SSH port?

Many guides recommend changing SSH from port 22 to a high-numbered port. This is security through obscurity. It stops the laziest bots that only try port 22. It does not stop any attacker running a port scan, which takes seconds.

The real cost: you now need to remember -p 2222 on every SSH command, configure it in every deploy script and CI pipeline, and risk locking yourself out if you forget. SSH key authentication with Fail2Ban provides actual security. Changing the port adds operational complexity for minimal gain.

The same logic applies to disabling IPv6. If your server has an IPv6 address, disabling it does not remove attack surface. It breaks future compatibility. Configure your firewall for both IPv4 and IPv6 instead.

Security layers at a glance

Each layer in this guide addresses a specific part of your defense. Here is how they stack:

Layer	What It Protects	Priority
System updates	Patches known vulnerabilities	Do first
User permissions	Limits blast radius of compromise	Do first
SSH hardening	Blocks unauthorized remote access	Do first
Firewall	Controls network exposure	Do first
Fail2Ban	Slows brute-force attacks	Do first
Automatic updates	Keeps patches current long-term	Set up in first week
VPN access	Hides internal services	When running non-public services
Kernel hardening	Limits exploit techniques	Advanced, production systems
Audit logging	Detects compromise after the fact	Advanced, compliance

The first five layers are non-negotiable for any server connected to the internet. The remaining layers add depth depending on what you run and your compliance requirements.

No single layer is sufficient on its own. SSH hardening without a firewall still leaves services exposed. A firewall without automatic updates leaves known vulnerabilities open. The layers work together. Each one catches what the others miss.

When should you use managed hosting instead?

If security management takes time away from building your product, consider managed hosting. This is not a failure. It is a resource allocation decision.

Signs you should consider managed hosting:

You run a production service but do not have time to monitor security advisories
Your team lacks Linux administration experience
You need compliance certifications (SOC 2, ISO 27001) and cannot staff the audit process
You have been compromised before and lack the expertise to investigate

A managed server from a provider like Virtua Cloud handles OS patching, firewall management, intrusion detection, and backups. You focus on your application. The provider handles the infrastructure security layer.

For teams that want VPS flexibility with partial security coverage, a middle ground exists: provision an unmanaged VPS for development and staging, and use managed hosting for production.

Something went wrong?

Check your SSH access

If you are locked out after changing SSH config:

Use your VPS provider's web console or serial console to access the server
Check the SSH configuration syntax: sudo sshd -t
Verify your key is in ~/.ssh/authorized_keys for the correct user
Check SSH logs: journalctl -u ssh -n 50 (Ubuntu) or journalctl -u sshd -n 50 (Debian)

Check your firewall

If a service is not reachable:

sudo ufw status numbered

Make sure the port is listed as ALLOW. If you just enabled UFW and forgot to allow SSH first, use the provider's web console.

Check Fail2Ban

If a legitimate IP got banned:

# Check if the IP is banned
sudo fail2ban-client status sshd

# Unban a specific IP
sudo fail2ban-client set sshd unbanip 1.2.3.4

Read the logs

The logs tell you what happened:

# SSH authentication
journalctl -u ssh -f     # Ubuntu 24.04
journalctl -u sshd -f    # Debian 12

# Fail2Ban activity
sudo tail -f /var/log/fail2ban.log

# Firewall blocks (if using nftables logging)
journalctl -k | grep nft

# System messages
journalctl -p err -b

Train yourself to read log output. Every time something breaks, the answer is almost always in the logs.

Next steps

This guide covers the security layers for a Linux VPS. Each section links to a detailed, hands-on tutorial:

Start with the first 5 security steps if you have not done them yet. Then work through the tutorials in order. Each one builds on the previous.