Linux Firewall Basics: ufw and firewalld Explained for Beginners

A firewall is a gatekeeper. It looks at network traffic arriving at your server and decides what is allowed in. On a typical web server, the answer should be very short: web traffic on ports 80 and 443, SSH for administration, and nothing else. This article explains how Linux firewalls work and how to manage them with the two most common front ends, ufw and firewalld.

Where the real work happens

Linux filters traffic inside the kernel. The older tool is iptables, and its successor is nftables. Writing rules for these directly is powerful but error-prone, so most distributions ship a friendlier layer on top. Ubuntu usually uses ufw (Uncomplicated Firewall); Red Hat style distributions such as AlmaLinux and Rocky Linux use firewalld. Pick the one that matches your distribution and use only one, because two managers fighting over the same rules cause confusing results.

The golden rule: default deny

A sound firewall policy blocks incoming traffic by default and allows only what you list. Outgoing traffic is usually allowed so the server can fetch updates. Everything below follows that model.

ufw on Ubuntu and Debian

Install it if needed (sudo apt install ufw), then set defaults and add allow rules before enabling:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Enabling the firewall without an SSH rule is the classic way to cut off your own connection. Allow SSH first. A few other useful commands:

• sudo ufw allow from 198.51.100.7 to any port 22 proto tcp allows SSH only from one address.
• sudo ufw status numbered followed by sudo ufw delete 3 removes rule number 3.
• sudo ufw limit OpenSSH rate-limits repeated connections from the same address.
• sudo ufw disable switches the firewall off, useful for short troubleshooting.
• sudo ufw allow 8080/tcp comment 'staging app' adds a note to the rule, which helps when you read the list months later.
• sudo ufw logging on records blocked connections in the system log, handy for seeing what is knocking.

firewalld on AlmaLinux and Rocky Linux

firewalld groups interfaces into zones and uses services by name. Start and enable it, then add services:

sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

The --permanent flag writes the rule to the saved configuration; without it the rule disappears at the next reload. Because the change does not take effect until you reload, remember the --reload step. To open a custom port such as 3000, use --add-port=3000/tcp, and to remove something use the matching --remove-service or --remove-port option.

Which ports should be open?

Service	Port	Open to the internet?
SSH	22/tcp	Yes, ideally restricted by address or rate-limited
HTTP	80/tcp	Yes, for web servers
HTTPS	443/tcp	Yes, for web servers
MySQL / MariaDB	3306/tcp	No, keep local unless you have a specific reason
PostgreSQL	5432/tcp	No, keep local
Redis	6379/tcp	No, never expose it publicly

Databases and caches should normally listen only on 127.0.0.1, with the firewall as a second barrier in case a configuration mistake changes that.

Limits, IPv6 and checking from outside

What a firewall does not do

A firewall controls which ports are reachable. It does not fix vulnerable software behind an open port, and it does not inspect your web application for attacks. Treat it as one layer next to updates, strong authentication and sensible application security.

Also be aware that Docker publishes container ports by editing firewall rules itself, which can bypass ufw rules. If you run containers, check the actual exposure with an external port scan of your own server, or bind published ports to localhost, for example -p 127.0.0.1:8080:80.

Verify from the outside

To see what is listening on the server itself, run sudo ss -tulpn. To see what is reachable from outside, test from another machine with a tool such as nmap, run only against servers you own. Compare the two: any listening service you did not expect deserves an explanation.

IPv6 and provider firewalls

If your server has an IPv6 address, your rules must cover it too. On Ubuntu, ufw handles IPv6 when IPV6=yes is set in /etc/default/ufw, which is the usual default; firewalld applies its rules to both families. Some hosts also offer a network-level firewall in front of the server. That can be a useful extra layer, but keep the rules on the server itself as well, so protection does not depend on one setting made in one place.

Changing rules without locking yourself out

Before editing firewall rules on a remote server, make sure you have a second way in, such as your provider's emergency console, and keep one SSH session open while you test from another. If you are experimenting with something risky, schedule an automatic rollback: for example, sudo ufw disable inside an at job that runs in ten minutes, cancelled once you confirm that everything works. This small habit prevents most self-inflicted lockouts. The knowledge base lists more troubleshooting steps.

Firewalls on your Zebra Hosting server

Whichever tool you choose, the principle is the same: deny first, allow deliberately. For a server where you control the firewall yourself, look at the VPS plans.