Ubuntu’s built-in software firewall is UFW - the Uncomplicated Firewall - and it is a friendly front end to iptables that turns a page of arcane rules into commands like sudo ufw allow 22. It ships on every Ubuntu install, disabled by default. The single most important thing to know before you enable it: allow SSH first. UFW’s default is to deny all incoming connections, so if you enable it on a remote server without an SSH rule, you lock yourself out of the box the instant it turns on.
UFW is genuinely simple once you follow the safe order. Here is that order, the handful of rules a normal server needs, and the mistake that strands you outside your own server.
Table of contents
- The safe setup order
- Opening the ports a server actually needs
- Managing and removing rules
- Rate limiting and logging
- How this fits the rest of the stack
- FAQ
The safe setup order
Do these in sequence. The order is the safety - allow access before you turn on the wall:
# 1. Set sane defaults: block incoming, allow outgoing
sudo ufw default deny incoming
sudo ufw default allow outgoing
# 2. ALLOW SSH BEFORE ENABLING - this is the step people skip
sudo ufw allow OpenSSH # or: sudo ufw allow 22/tcp
# 3. Now it is safe to enable
sudo ufw enable
# 4. Confirm
sudo ufw status verboseIf you run sudo ufw enable before step 2 on a remote server, your current SSH session may survive but the next one will not - and you have no way back in. On a cloud server without console access, that is a rebuild. Allow SSH first, every time.
Opening the ports a server actually needs
sudo ufw allow 80/tcp # HTTP
sudo ufw allow 443/tcp # HTTPS
sudo ufw allow 'Nginx Full' # app-profile shortcut for 80 + 443
# Allow a port only from a specific IP
sudo ufw allow from 203.0.113.5 to any port 5432 proto tcpOpen only what you serve. A web server needs 80 and 443; a database port like 5432 should almost never be open to the whole internet - scope it to the IPs that need it with the from syntax. Every open port is attack surface, so the discipline is to allow the specific service and nothing else.
Managing and removing rules
sudo ufw status numbered # list rules with index numbers
sudo ufw delete 3 # delete rule number 3
sudo ufw deny 23 # explicitly block a port (telnet)
sudo ufw reset # wipe all rules and start overstatus numbered then delete <n> is the reliable way to remove a rule - deleting by number avoids retyping the exact rule specification. ufw reset disables the firewall and clears every rule, which is your escape hatch if the rule set gets tangled. After a reset, walk the safe setup order again from the top, SSH first.
Rate limiting and logging
sudo ufw limit ssh # throttle repeated SSH connection attempts
sudo ufw logging on # log blocked traffic to /var/log/ufw.logufw limit ssh blocks an IP that makes too many connection attempts in a short window - a cheap, effective brake on brute-force login attempts. Turn logging on so you can see what is being blocked; the log is where you notice a probe or confirm a rule is doing its job. Neither is required, but both are easy wins on any internet-facing server.
How this fits the rest of the stack
A firewall is one of those things that is either set up carefully or it locks you out of your own server - the safe order is the whole skill. Managed platforms handle this layer for you, exposing only the ports your service actually serves and keeping the host firewall out of your hands. The RunxBuild hosting calculator shows a service and its bandwidth as line items, and the RunxBuild dashboard runs your app behind managed networking so you are not one bad UFW rule away from a rebuild.
Useful related references:
- How to check your IP address on Ubuntu
- Firewall in cloud computing, explained
- How to remove a firewall rule
- Services on RunxBuild
FAQ
What is the software firewall on Ubuntu?
It is UFW, the Uncomplicated Firewall, a command-line front end to iptables that ships on every Ubuntu system. It makes firewall management approachable with commands like sudo ufw allow 443 instead of raw iptables rules. UFW is installed but disabled by default, so you configure your rules and then enable it. A graphical version, GUFW, exists for desktops.
How do I enable UFW without locking myself out?
Allow SSH before enabling. UFW defaults to denying all incoming connections, so on a remote server run sudo ufw allow OpenSSH (or sudo ufw allow 22/tcp) first, then sudo ufw enable. If you enable it without an SSH rule, the next connection attempt is blocked and you can be locked out of a server with no console access, which may mean a rebuild.
How do I open a port in UFW?
Use sudo ufw allow followed by the port, such as sudo ufw allow 80/tcp for HTTP or sudo ufw allow 443/tcp for HTTPS. Application profiles like sudo ufw allow ‘Nginx Full’ open related ports together. To restrict a port to a specific source, use sudo ufw allow from 203.0.113.5 to any port 5432, which is the safe way to expose a database.
How do I delete a UFW rule?
Run sudo ufw status numbered to list the rules with index numbers, then sudo ufw delete followed by the number, for example sudo ufw delete 3. Deleting by number avoids retyping the exact rule. If the rule set becomes confusing, sudo ufw reset clears everything and disables the firewall, after which you should redo the safe setup order starting with SSH.
Should I use a software firewall if my cloud provider has one?
They complement each other. A cloud provider’s network firewall or security group filters traffic before it reaches the instance, while UFW runs on the host itself as a second layer. On a self-managed server, running both is sensible defense in depth. On a fully managed platform, the provider typically handles this layer and only exposes the ports your service needs, so you may not touch UFW at all.