7 Quick Steps to Harden a New Linux VPS in 10 Minutes

Setting up a new virtual private server (VPS) is exciting, but security should be the first item on your checklist. A fresh Linux VPS can be hardened in a few minutes, giving you a solid foundation for any website, application, or service you plan to run. The steps below work on the most common distributions – Debian/Ubuntu (using apt) and AlmaLinux/Rocky / RHEL (using dnf). Windows Server follows a different model and is not covered here.

1. Update the system and install essential packages

Keeping the base system up‑to‑date closes known vulnerabilities before they can be exploited.

Debian / Ubuntu (apt)

# Refresh the package index
sudo apt update

# Upgrade all installed packages to the latest versions
sudo apt full-upgrade -y

# Install useful security tools
sudo apt install -y fail2ban ufw auditd

AlmaLinux / Rocky / RHEL (dnf)

# Refresh the repository metadata
sudo dnf check-update

# Apply all available updates
sudo dnf upgrade -y

# Install security utilities
sudo dnf install -y fail2ban firewalld audit

What each command does:

• update / check-update – contacts the configured repositories and downloads the latest package lists.
• full-upgrade / upgrade – installs newer versions, handling dependencies and removing obsolete packages when required.
• install – adds the listed tools, which will be used in later steps.

2. Create a non‑root administrative user

Running daily tasks as root is risky. A dedicated user with sudo privileges limits the impact of accidental commands and isolates attacks.

Both distributions

# Replace "adminuser" with your preferred username
sudo adduser adminuser

# Add the new user to the sudo (or wheel) group
# Debian/Ubuntu
sudo usermod -aG sudo adminuser

# AlmaLinux/Rocky/RHEL
sudo usermod -aG wheel adminuser

After creating the account, log out of the root session and log back in as adminuser. Verify that sudo works with:

sudo -v

3. Harden SSH access

Secure Shell (SSH) is the primary remote‑login method. A few tweaks dramatically reduce the attack surface.

Common steps (both OS families)

# Open the SSH configuration file with a safe editor
sudo nano /etc/ssh/sshd_config

Make the following changes (add or modify lines as needed):

• Port 2222 – move SSH to a non‑standard port (choose any unused port above 1024).
• PermitRootLogin no – disable direct root logins.
• PasswordAuthentication no – require key‑based authentication.
• AllowUsers adminuser – restrict login to the user you just created.

After editing, restart the SSH service:

Debian / Ubuntu

sudo systemctl restart sshd

AlmaLinux / Rocky / RHEL

sudo systemctl restart sshd

Generate an SSH key pair on your workstation (if you don’t already have one) and copy the public key to the VPS:

# On your workstation
ssh-keygen -t ed25519 -C "your_email@example.com"

# Transfer the public key
ssh-copy-id -p 2222 adminuser@your-vps-ip

4. Configure a minimal firewall

A host‑based firewall blocks unwanted traffic before it reaches any services.

Debian / Ubuntu (UFW)

# Allow the new SSH port
sudo ufw allow 2222/tcp

# Permit HTTP/HTTPS if you plan to run a web server
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Enable the firewall
sudo ufw enable

AlmaLinux / Rocky / RHEL (Firewalld)

# Open the new SSH port
sudo firewall-cmd --permanent --add-port=2222/tcp

# Open HTTP/HTTPS ports
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https

# Reload to apply changes
sudo firewall-cmd --reload

Both ufw and firewalld are front‑ends for iptables. The commands above create rules that persist across reboots.

5. Enable Fail2Ban to thwart brute‑force attacks

Fail2Ban monitors log files and temporarily bans IPs that show malicious behavior, such as repeated failed SSH logins.

Configuration (both OS families)

# Copy the default jail template
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

# Edit the local file
sudo nano /etc/fail2ban/jail.local

Locate the [sshd] section and ensure it is enabled:

[sshd]
enabled = true
port    = 2222
logpath = %(sshd_log)s
maxretry = 5
bantime = 3600

Start and enable the service:

Debian / Ubuntu

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

AlmaLinux / Rocky / RHEL

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

6. Activate auditing and log rotation

System auditing records privileged actions, while log rotation prevents log files from consuming disk space.

Auditd (both families)

# Ensure auditd starts on boot
sudo systemctl enable auditd
sudo systemctl start auditd

The default audit rules already capture most sudo and file‑access events. View recent entries with:

sudo ausearch -m USER_CMD -ts recent

Logrotate (both families)

# Verify the default configuration
cat /etc/logrotate.conf

# Perform a dry‑run test (does not affect live logs)
sudo logrotate -d /etc/logrotate.conf

If you add custom log files (e.g., from an application), place a configuration file in /etc/logrotate.d/ with the standard rotation parameters.

7. Disable unnecessary services

Every running daemon is a potential entry point. List active services and stop anything you don’t need.

List enabled services (both families)

systemctl list-unit-files --type=service | grep enabled

Typical services you can disable on a minimal VPS include:

• avahi-daemon – local network discovery.
• cups – printer service.
• exim4 or postfix – mail servers, unless required.

Disable example (Debian / Ubuntu)

sudo systemctl disable avahi-daemon
sudo systemctl stop avahi-daemon

Disable example (AlmaLinux / Rocky / RHEL)

sudo systemctl disable avahi-daemon
sudo systemctl stop avahi-daemon

After trimming services, run systemctl daemon-reload to refresh the manager’s state.

Conclusion

By following these seven steps—updating packages, creating a sudo user, hardening SSH, configuring a firewall, installing Fail2Ban, enabling auditing, and disabling unused services—you can secure a brand‑new Linux VPS in under ten minutes. The process is repeatable, works on the major Debian‑based and RHEL‑based distributions, and provides a strong baseline for any application you plan to host. From here, you can add application‑specific hardening (web‑server configs, database permissions, etc.) with confidence that the underlying system is already protected.