SERVER HARDENING
June 24, 2026

Ubuntu 24.04 Server Hardening: The Complete Checklist

9 min read
Author
CloudStick Team
Server Infrastructure
Share this article
Ubuntu 24.04 Server Hardening
CloudStick
Complete Hardening Checklist

Step 1: Update and Patch the System

The first thing you do on any new Ubuntu 24.04 server is apply all pending updates. A fresh server from a cloud provider may be hours or days behind on security patches — vulnerabilities exploited in the wild may already have fixes waiting in the package manager.

sudo apt update && sudo apt upgrade -y
sudo apt autoremove -y
sudo reboot

After the reboot, check what kernel is running with uname -r. You want the latest HWE (Hardware Enablement) kernel on Ubuntu 24.04 LTS. Enable unattended security updates — covered in step 5 — so future patches apply automatically.

Ubuntu 24.04 LTS ships with unattended-upgrades pre-installed. It is not always enabled by default — confirm it is running with systemctl status unattended-upgrades.

Step 2: Create a Sudo User and Disable Root Login

Operating as root is dangerous — a single typo can wipe the system, and any compromised process running as root can do anything. Create a dedicated sudo user and lock the root account from direct SSH access.

# Create a new user
sudo adduser deploy
# Add to the sudo group
sudo usermod -aG sudo deploy
# Switch to the new user and test sudo
su - deploy
sudo whoami # should print: root

Once confirmed working, disable root SSH login by editing /etc/ssh/sshd_config and setting PermitRootLogin no. Reload SSH with sudo systemctl reload ssh.

Step 3: Harden SSH Access

SSH is the primary entry point to your server. Password-based SSH authentication is vulnerable to brute-force attacks — switch to key-based auth and disable passwords entirely. Copy your public key first, then lock things down:

# From your local machine
ssh-copy-id deploy@your-server-ip
# Then on the server, edit /etc/ssh/sshd_config:
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
X11Forwarding no
AllowTcpForwarding no
sudo systemctl reload ssh

WARNING: Never close your current SSH session until you have confirmed that key-based login works from a second terminal window. Locking yourself out requires console access through your cloud provider.

Additional SSH hardening: change the default port from 22 to a non-standard port (e.g. 2222), restrict SSH access to specific IP ranges using AllowUsers directives, and set MaxAuthTries 3 to limit brute-force attempts per connection.

Step 4: Configure UFW Firewall

UFW (Uncomplicated Firewall) is the standard firewall tool on Ubuntu. The default policy should deny all incoming traffic and allow all outgoing, then explicitly allow only what you need.

# Set default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing
# Allow SSH (adjust port if you changed it)
sudo ufw allow 22/tcp
# Allow web traffic
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# Enable and verify
sudo ufw enable
sudo ufw status verbose

If you are running a database server, keep MySQL (3306) and Redis (6379) blocked on the public interface — they should only be accessible on the loopback interface (127.0.0.1) or through a VPN. Exposing database ports to the internet is one of the most common server security mistakes.

Step 5: Install Fail2Ban

Even with key-based SSH auth, attackers will still pound your server with connection attempts. Fail2Ban watches log files and bans IPs after a configurable number of failed attempts, making brute-force attacks computationally impractical.

sudo apt install fail2ban -y
# Create a local config (never edit jail.conf directly)
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
# Edit /etc/fail2ban/jail.local and set:
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo fail2ban-client status sshd

Additional Hardening Steps

The checklist above covers the critical baseline. Here are additional steps to consider depending on your threat model:

  • Enable automatic security updates — Configure unattended-upgrades to apply security patches automatically without requiring manual apt upgrade runs.
  • Remove unused packages — Run sudo apt autoremove and audit installed services with systemctl list-units --type=service --state=running. Stop anything you do not need.
  • Set correct file permissions — World-writable files are a privilege escalation risk. Run find / -xdev -type f -perm -0002 to find them.
  • Enable AppArmor — Ubuntu 24.04 ships with AppArmor enabled and pre-configured profiles for common services. Verify with sudo aa-status.
  • Audit open ports regularly — Use ss -tulpn to list all listening ports and verify each one is expected.
  • Configure sysctl hardening — Add network-level hardening via /etc/sysctl.d/99-hardening.conf to disable IP source routing, enable SYN flood protection, and ignore ICMP redirects.

TIP: Run the Lynis security auditing tool after hardening — sudo apt install lynis && sudo lynis audit system — to get a scored report and additional recommendations specific to your configuration.

CloudStick Automates Server Hardening

When you connect a server to CloudStick, the agent install process applies a security baseline automatically: SSH key management, firewall configuration via the dashboard, Fail2Ban rules, and automatic security updates — all configured without requiring you to run any of the commands above manually.

CloudStick's firewall panel lets you manage UFW rules visually — add, remove, and review ingress rules for any server without touching the command line. SSH key management is built into the vault, letting you add and revoke team member keys from the same dashboard where you manage websites and databases. For teams managing multiple servers, this eliminates the risk of inconsistent hardening across different machines.

Leave a comment
Full Name
Email Address
Message
On this page

We use cookies to improve your experience

CloudStick uses cookies to personalise content, analyse traffic and keep you signed in. Cookie Policy · Terms of Service

Manage cookies