You've spun up a new Linux server and someone told you to configure a firewall. Maybe you've heard the term UFW thrown around but don't know where to start. A firewall controls which network traffic reaches your machine, and UFW makes that job easier than writing raw iptables rules by hand.
This guide assumes you know nothing about firewalls. We'll define every concept, install UFW, write your first rules, and leave you with a working setup that protects your server without locking you out.
What a firewall actually does
A firewall sits between your server and the internet. Every packet trying to reach your machine passes through it first. The firewall checks a list of rules and decides: allow this through or drop it.
Without a firewall, every service listening on a port is reachable from anywhere. A database accidentally bound to 0.0.0.0 becomes a public target. A test API you forgot about stays exposed. A firewall gives you a default-deny posture: block everything except what you explicitly permit.
Think of it as a bouncer at a club. You hand the bouncer a list of people allowed in. Everyone else gets turned away at the door.
UFW vs iptables
Linux has a built-in firewall called iptables (or its newer cousin nftables). Both are powerful but use a syntax that looks like assembly code. A single rule to allow SSH might span three lines and reference chains, tables, and jump targets.
UFW stands for Uncomplicated Firewall. It's a command-line tool that translates simple English-like commands into iptables rules behind the scenes. You type ufw allow 22/tcp instead of memorizing iptables syntax. UFW ships with Ubuntu and Debian by default and works on any Linux distribution that uses iptables.
You're not replacing iptables; you're using a friendlier interface on top of it.
Installing UFW
On Ubuntu or Debian:
sudo apt update
sudo apt install ufw
On CentOS, Rocky, or AlmaLinux:
sudo yum install epel-release
sudo yum install ufw
On Arch:
sudo pacman -S ufw
After installation, UFW is present but disabled. The firewall isn't active yet, so you won't lock yourself out during setup.
Checking UFW status
Run:
sudo ufw status
You'll see:
Status: inactive
That means UFW is installed but not enforcing any rules. Traffic flows freely for now.
The golden rule: allow SSH before you enable UFW
If you're working on a remote server over SSH, enabling a firewall without allowing SSH will cut your connection. You'll be locked out. The server will keep running but you won't be able to log back in without console access.
Always add an SSH rule first.
Allow SSH (port 22)
sudo ufw allow 22/tcp
If your SSH daemon listens on a non-standard port (say, 2222), use that number instead:
sudo ufw allow 2222/tcp
You can also use the service name:
sudo ufw allow ssh
UFW looks up the port for the ssh service in /etc/services and creates the rule. I prefer typing the port number because it's explicit and you see exactly what's being opened.
Enabling UFW
Now that SSH is allowed, turn on the firewall:
sudo ufw enable
You'll see:
Firewall is active and enabled on system startup
UFW is now filtering traffic. Check the status again:
sudo ufw status
Output:
Status: active
To Action From
-- ------ ----
22/tcp ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)
Notice UFW created two rules: one for IPv4, one for IPv6. If your server has an IPv6 address, both matter.
What just happened?
By default, UFW's policy is:
- Deny all incoming connections
- Allow all outgoing connections
Your server can initiate outbound requests (install packages, fetch updates, query DNS) but nothing can reach it from the outside unless you explicitly allow it. The only exception right now is SSH on port 22.
Opening ports for common services
Let's say you're running a web server. You need to allow HTTP (port 80) and HTTPS (port 443):
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
Or in one line:
sudo ufw allow 80,443/tcp
For a mail server, open the standard ports:
sudo ufw allow 25/tcp # SMTP
sudo ufw allow 587/tcp # submission
sudo ufw allow 993/tcp # IMAPS
For MySQL or MariaDB (if you must expose the database, though you usually shouldn't):
sudo ufw allow 3306/tcp
UFW accepts both port numbers and protocol keywords. tcp and udp are the most common. If you omit the protocol, UFW allows both.
Allowing traffic from specific IPs
Sometimes you want to lock a service down to a single IP address. Maybe you're running a database and only your application server should reach it.
sudo ufw allow from 203.0.113.50 to any port 3306 proto tcp
This rule allows 203.0.113.50 to connect to port 3306 over TCP. Everyone else gets blocked.
You can also allow an entire subnet:
sudo ufw allow from 10.0.1.0/24 to any port 22
Now any machine in the 10.0.1.0/24 range can SSH in, but the rest of the internet cannot.
Denying traffic explicitly
By default, UFW denies everything not explicitly allowed. But you can add explicit deny rules for clarity or to override a broader allow rule.
sudo ufw deny from 198.51.100.10
This blocks all traffic from that IP, even if another rule would allow it. Deny rules are processed before allow rules in UFW's logic.
Deleting rules
List your rules with line numbers:
sudo ufw status numbered
Output:
Status: active
To Action From
-- ------ ----
[ 1] 22/tcp ALLOW IN Anywhere
[ 2] 80/tcp ALLOW IN Anywhere
[ 3] 443/tcp ALLOW IN Anywhere
Delete rule 2 (HTTP):
sudo ufw delete 2
Or delete by specifying the rule itself:
sudo ufw delete allow 80/tcp
Both methods work. I find numbered deletion faster when you have many rules.
So what if you lock yourself out?
If you're on a VPS or cloud instance, your provider's control panel usually offers a web-based console or recovery mode. Boot into that, disable UFW (sudo ufw disable), fix your rules, then re-enable.
If you're on a physical machine, you have console access by default. Same fix.
The real danger is enabling UFW without allowing SSH on a remote server with no console access. Follow the golden rule and you'll be fine.
Resetting UFW to defaults
Made a mess and want to start over?
sudo ufw reset
This disables UFW, deletes all rules, and restores the default policies. You'll need to re-enable and re-add your rules afterward.
Logging
UFW can log blocked and allowed connections. Turn on logging:
sudo ufw logging on
Logs appear in /var/log/ufw.log. You'll see entries for blocked packets, which helps you spot brute-force attempts or misconfigurations.
Logging has levels: low, medium, high, full. Medium is a good default:
sudo ufw logging medium
High and full generate a lot of noise. Use them only when troubleshooting.
Application profiles
UFW ships with pre-configured profiles for common services. List them:
sudo ufw app list
You might see:
Available applications:
Apache
Apache Full
Apache Secure
OpenSSH
To allow Apache (HTTP and HTTPS):
sudo ufw allow 'Apache Full'
This is shorthand for allowing ports 80 and 443. Profiles live in /etc/ufw/applications.d/. You can write custom profiles for your own services if you want, but manually specifying ports is just as fast.
Rate limiting to block brute force
SSH brute-force bots will hammer port 22 with login attempts. UFW can rate-limit connections:
sudo ufw limit 22/tcp
This allows up to six connections from a single IP within thirty seconds. After that, UFW drops new connection attempts from that IP for a while. Rate limiting slows down automated attacks without blocking legitimate users.
Checking which ports are listening
Before you open a port in UFW, confirm something is actually listening on it. Use ss:
sudo ss -tuln
You'll see a list of open ports and the services bound to them. If port 80 isn't listed, opening it in UFW won't help because nothing is listening.
In support tickets I handled, the usual mistake was opening the firewall without starting the service. Check both layers.
Default policies
UFW's defaults are sensible for most servers. If you want to see them:
sudo ufw default deny incoming
sudo ufw default allow outgoing
These commands set the policies explicitly. Incoming traffic is blocked unless a rule allows it. Outgoing traffic is permitted by default.
You can also deny outgoing if you want a locked-down environment:
sudo ufw default deny outgoing
Then you'd need to allow specific outbound connections (DNS, HTTP for updates, etc.). Most people don't need this level of restriction.
Testing your firewall
From another machine, try to connect to a port you didn't open. Use telnet or nc:
telnet your-server-ip 3306
If UFW is working, the connection will hang and eventually time out. If it connects, either UFW isn't enabled or a rule is allowing it.
Test the ports you did open the same way. SSH should connect, HTTP should return a response if your web server is running, and so on.
A working baseline setup
Here's a checklist for a typical web server:
- Install UFW:
sudo apt install ufw - Allow SSH first:
sudo ufw allow 22/tcp - Allow HTTP and HTTPS:
sudo ufw allow 80,443/tcp - Enable UFW:
sudo ufw enable - Check status:
sudo ufw status - Enable logging:
sudo ufw logging medium - Rate-limit SSH:
sudo ufw limit 22/tcp
That's a solid starting point. Adjust port numbers to match your services.
When UFW isn't enough
UFW is great for simple, host-based firewalling. It won't replace a network firewall appliance or cloud security groups. If you're running a multi-server environment, use your cloud provider's firewall features (AWS security groups, DigitalOcean cloud firewalls, etc.) as the first layer and UFW as a second.
UFW also doesn't do deep packet inspection or application-layer filtering. For that, you need something like Fail2Ban (which watches logs and bans IPs) or a web application firewall.
FAQ
Does UFW work on CentOS or RHEL?
Yes, after installing it from EPEL. CentOS and RHEL default to firewalld, but you can use UFW instead if you prefer its syntax. Don't run both at once.
Can I use UFW on a server that already has iptables rules?
UFW will overwrite existing iptables rules when you enable it. If you have custom iptables rules, back them up first. You can integrate UFW with existing rules by editing /etc/ufw/before.rules and /etc/ufw/after.rules, but that defeats UFW's simplicity.
What happens if I reboot?
UFW starts automatically on boot if you enabled it with sudo ufw enable. Your rules persist across reboots.
Do I need to restart UFW after adding a rule?
No. Rules take effect immediately. You only need to enable UFW once, at the beginning.
How do I allow a port range?
Use a colon: sudo ufw allow 6000:6100/tcp. This opens ports 6000 through 6100.
What to check first when something breaks
If a service suddenly stops accepting connections after you enabled UFW, check these in order:
- Is UFW active?
sudo ufw status - Is the port listed in the rules? Look for your port in the status output.
- Is the service actually running and listening?
sudo ss -tuln | grep <port> - Did you specify the right protocol (tcp vs udp)?
- Are you testing from an IP that's allowed? Review any
fromrestrictions in your rules. - Check
/var/log/ufw.logfor blocked packets from your test IP.
Most issues come down to forgetting to open a port or specifying the wrong protocol. UFW's numbered status output makes it easy to audit your rules. Keep the list short and document what each rule is for, either in a comment file or a runbook, so you remember why you opened port 8080 six months from now.