Knowledge Base / Security

Ubuntu Server Security: UFW, fail2ban, SSH Hardening

Last updated: 23 September 2026

Every server exposed to the internet is subjected to automated attack scanning from the first minute it is up. The good news: basic hardening makes the vast majority of attacks pointless. This guide secures a new Ubuntu 22.04/24.04 server in the first hour.

This guide assumes you have completed the First VPS Setup steps (sudo user, system update). If not, do that first.

1. Stay up to date

Unpatched software is the number one cause of server compromises.

sudo apt update && sudo apt upgrade -y

Enable automatic security updates:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

2. Firewall: UFW

UFW (Uncomplicated Firewall) leaves only the ports you actually need open.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable
sudo ufw status verbose
Before the ufw enable command, you must run ufw allow OpenSSH. Otherwise your active SSH session drops and you cannot reach the server.

Never expose services like the database (3306) or Redis (6379) to the internet — access them only over localhost or a private network.

3. SSH hardening

First set up an SSH key and confirm it works. Then, in /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
X11Forwarding no
MaxAuthTries 3
sudo systemctl restart ssh

Do I need to change the SSH port?

Not required. If key login is mandatory, staying on the default port 22 is not a security problem; you can pick a different port just to reduce log noise. If you change it, update the UFW rule too.

4. fail2ban

fail2ban automatically bans IPs that repeatedly make failed login attempts.

sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

The [sshd] section in /etc/fail2ban/jail.local:

[sshd]
enabled = true
maxretry = 3
bantime = 1h
findtime = 10m
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

5. Shared responsibility: the application layer

  • Web server: disable the server signature in Nginx/Apache, add security headers (HSTS, X-Content-Type-Options, X-Frame-Options).
  • Database: separate, strong passwords; bind-address = 127.0.0.1; delete unused default accounts.
  • Application: keep the framework and dependencies up to date; do not put .env and backup files in the web root.
  • SSL: HTTPS on every site with Let's Encrypt.

6. Backups — an inseparable part of security

Against ransomware, deletion mistakes or disk failure, a backup is the only real protection.

  • The 3-2-1 rule: 3 copies, 2 different media, 1 in a different location.
  • Send backups to another server/storage — a backup on the same server is gone when the server is gone.
  • Do a restore test once a month; an untested backup is not a backup.

7. Monitoring

  • sudo journalctl -u ssh --since "1 hour ago" — login attempts
  • sudo lastb — failed logins
  • sudo apt install auditd -y — system-call auditing (optional, advanced)
  • Use an uptime/monitoring service to check from the outside that the server is up.

Quick checklist

  • ☐ System up to date + unattended-upgrades on
  • ☐ UFW enabled, only 22/80/443 open
  • ☐ SSH: root off, password off, key mandatory
  • ☐ fail2ban running
  • ☐ Database bound to localhost only
  • ☐ Automatic, off-server backup + restore test
  • ☐ All sites on HTTPS
At Arcnar: Compute plans come with an up-to-date Ubuntu image; network security groups are managed from the panel. Managed scaling and automatic backup options are on the roadmap — for critical data, set up your own off-server backup.

Frequently asked questions

What is the minimum I should do to secure a new Ubuntu server?
Update the system and enable unattended-upgrades; with UFW leave only ports 22/80/443 open; disable root and password login over SSH and require a key; install fail2ban; bind the database to localhost only; set up automatic, off-server backups.
Does changing the SSH port from 22 really improve security?
It only reduces log noise — this is "security through obscurity", not real protection. If key login is mandatory, staying on port 22 is not a security problem. If you change it, do not forget to update the UFW rule too.
What does fail2ban do?
It watches the server logs and automatically bans, in the firewall, IP addresses that make many failed login attempts in a short time. It largely stops brute-force attacks against SSH, the web panel and mail services.
Is backup part of security?
Yes, one of the most important parts. Against ransomware, accidental deletion or disk failure, a backup is the only real protection. Apply the 3-2-1 rule (3 copies, 2 media, 1 in a different location) and do a restore test once a month.

Was this article helpful?