Set Up UFW Firewall on Ubuntu 24.04 — Secure Your Server in 5 Steps

Introduction

Every Ubuntu server exposed to the internet is a target the moment it's provisioned. Automated scanners probe public IP addresses continuously — within minutes of launching a new Raff VM, your server will receive connection attempts on ports you never intended to open. A firewall is the first line of defence that determines which of those attempts are even allowed to reach your services.

UFW (Uncomplicated Firewall) is Ubuntu's built-in firewall management tool. It sits on top of iptables and provides a readable, consistent command syntax that makes firewall configuration approachable without hiding the underlying power. UFW is installed by default on Ubuntu 24.04 but not enabled — meaning your server is reachable on every port until you configure and activate it.

It's worth noting that Raff VMs already benefit from network-level DDoS protection and a platform firewall included on every plan. UFW adds a second layer of defence at the operating system level, giving you fine-grained control over which ports and services are accessible on your specific server. Defence in depth — multiple independent layers of protection — is the principle that separates servers that survive incidents from those that don't.

In this tutorial, you will install and verify UFW, allow SSH access before enabling the firewall (skipping this step is the most common way people lock themselves out), configure rules for common services, enable the firewall, and verify everything is working correctly.

Step 1 — Verify UFW Is Installed

UFW comes pre-installed on Ubuntu 24.04, but it's worth confirming before proceeding. Run the following command to check:

bashsudo ufw status

If UFW is installed and inactive, you will see:

Status: inactive

If the command is not found, install UFW with:

bashsudo apt update && sudo apt install -y ufw

Step 2 — Allow SSH Before Enabling the Firewall

This is the most important step in the entire tutorial. If you enable UFW before allowing SSH, you will immediately lose access to your server and will need to use the Raff web console to recover.

UFW ships with pre-defined application profiles for common services. SSH has a built-in profile called OpenSSH. Allow it now:

bashsudo ufw allow OpenSSH

You should see:

Rules updated
Rules updated (v6)

Verify the rule is in place before moving on:

bashsudo ufw show added

You should see ufw allow OpenSSH listed. Do not proceed to Step 3 until this rule is confirmed.

If you connect to SSH on a non-standard port (not 22), allow that specific port instead:

bashsudo ufw allow 2222/tcp

Replace 2222 with your actual SSH port.

Step 3 — Configure Rules for Your Services

With SSH protected, you can now add rules for any other services running on your server. Only allow ports and services you are actually using — every open port is a potential attack surface.

Allow HTTP and HTTPS (Web Servers)

If you are running Nginx or Apache:

bashsudo ufw allow 'Nginx Full'

Nginx Full allows both port 80 (HTTP) and port 443 (HTTPS) in a single rule. To allow only HTTPS:

bashsudo ufw allow 'Nginx HTTPS'

If you are running Apache instead:

bashsudo ufw allow 'Apache Full'

Allow Specific Ports

For services without a named UFW profile, allow by port number and protocol:

bashsudo ufw allow 3000/tcp

This example allows TCP traffic on port 3000, which is the default port for Node.js development servers. Replace 3000 with whatever port your application uses.

For a range of ports:

bashsudo ufw allow 8000:8080/tcp

Allow Traffic from a Specific IP Address

To restrict a service to a single trusted IP — useful for database access or admin panels:

bashsudo ufw allow from 203.0.113.10 to any port 5432

This allows PostgreSQL connections (port 5432) only from the IP address 203.0.113.10. Replace the IP and port with your actual values.

Deny Specific Ports

UFW's default policy (which you will set in the next step) blocks all incoming traffic that doesn't match an allow rule. You generally don't need explicit deny rules unless you want to block traffic from a specific IP:

bashsudo ufw deny from 198.51.100.5

Step 4 — Set Default Policies and Enable UFW

Before enabling UFW, set the default policies. The secure baseline is:

• Deny all incoming traffic by default (only explicitly allowed ports are accessible)
• Allow all outgoing traffic by default (your server can make requests to the internet)

bashsudo ufw default deny incoming
sudo ufw default allow outgoing

Now enable the firewall:

bashsudo ufw enable

UFW will warn you that enabling the firewall may disrupt existing SSH connections:

Command may disrupt existing ssh connections. Proceed with operation (y|n)?

Type y and press Enter. Because you allowed OpenSSH in Step 2, your current session will not be interrupted.

You should see:

Firewall is active and enabled on system startup

UFW is now active and will automatically start on every boot.

Step 5 — Verify the Firewall Configuration

Confirm that UFW is active and your rules are correctly applied:

bashsudo ufw status verbose

Expected output for a server running SSH and Nginx:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp (OpenSSH)           ALLOW IN    Anywhere
80,443/tcp (Nginx Full)    ALLOW IN    Anywhere
22/tcp (OpenSSH (v6))      ALLOW IN    Anywhere (v6)
80,443/tcp (Nginx Full (v6)) ALLOW IN  Anywhere (v6)

Check that:

• Status: active is shown
• Default: deny (incoming) is set
• OpenSSH appears in the rules
• Only the services you intentionally allowed are listed

To view rules with index numbers (useful for deleting specific rules later):

bashsudo ufw status numbered

Test that SSH still works by opening a new terminal window and connecting to your server before closing your current session. This confirms the firewall is not blocking your access.

Managing UFW Rules After Setup

Here are the commands you will use most frequently after initial configuration.

Delete a Rule

First, find the rule's index number:

bashsudo ufw status numbered

Then delete by number:

bashsudo ufw delete 3

Alternatively, delete by rule specification:

bashsudo ufw delete allow 3000/tcp

Disable UFW Temporarily

bashsudo ufw disable

This stops the firewall without deleting your rules. Run sudo ufw enable to reactivate.

Reset All Rules

bashsudo ufw reset

Reload UFW After Rule Changes

UFW applies rules immediately when you add or delete them — you do not need to reload after individual changes. If you edit UFW's configuration files directly, reload with:

bashsudo ufw reload

Conclusion

Your Raff Ubuntu 24.04 VM now has a properly configured OS-level firewall. UFW is active, SSH is protected, and only the ports you explicitly allowed are reachable from the internet. The default deny policy means any new ports your applications open will not be automatically exposed — you must consciously allow them.

The three rules to remember for ongoing security hygiene:

• Least privilege: only open ports you are actively using
• Restrict by IP where possible: databases and admin panels should never be world-accessible
• Verify after every change: run sudo ufw status verbose after adding or removing rules

From here, consider these next steps to continue hardening your server:

• Secure SSH access further by disabling password authentication and enforcing key-only login
• Install and configure fail2ban to automatically block IPs that repeatedly fail SSH authentication
• Review the firewall best practices guide for a conceptual framework on rule design, segmentation, and ongoing maintenance

Raff's platform firewall and DDoS protection work alongside UFW — together they give your Linux VM defence at the network level and the operating system level. Neither replaces the other, and running both is the correct approach for any internet-facing server.

This tutorial was tested on a Raff Tier 2 VM running Ubuntu 24.04 LTS. Every command was verified in a clean environment with no pre-existing firewall rules.