Securing a Linux Server: Part 1 — The UFW Firewall

Firewall — the first thing you set up on a new server, even before Fail2ban, CrowdSec, and auditing. Its job is simple: allow only the traffic needed by running services and drop everything else. The fewer open ports, the fewer points through which the server can be attacked.

On Debian and Ubuntu this is usually done with UFW (Uncomplicated Firewall). This is not a separate firewall, but a utility that turns short commands into Linux kernel rules. UFW calls iptables, and on modern Debian and Ubuntu iptables runs on top of nftables, so the rules ultimately end up in nftables.

Default policy

The right starting point is to deny all incoming connections and allow outgoing:

sudo ufw default deny incoming
sudo ufw default allow outgoing

After that, open only the ports you need. Anything not explicitly allowed will be dropped.

SSH first, then enable

The most common mistake is enabling UFW on a remote server without allowing SSH. The connection will be cut off, and you’ll only be able to access the server via the provider’s console. UFW documentation explicitly recommends adding a rule for SSH before enabling: you can add rules while the firewall is off.

sudo ufw allow 22/tcp          # or your non-standard SSH port
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

If SSH listens on a different port, open that port. If the server is accessed only from the office, it’s better to restrict access by address:

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

Connection rate limiting

The limit command allows connections but rejects an address that tries to open 6 or more connections within 30 seconds. For SSH this is a simple protection against fast password-guessing:

sudo ufw limit 22/tcp

limit does not replace Fail2ban: it does not read logs and doesn’t know whether a login was successful or not. It’s a coarse but useful first filter.

Order of rules

UFW checks rules from top to bottom and the first matching rule applies. If allow 22 comes first and below it is deny from 198.51.100.0/24, the deny for that network on SSH will not work. View the order and insert a rule in the right place:

sudo ufw status numbered
sudo ufw insert 1 deny from 198.51.100.0/24
sudo ufw delete 3

IPv6

By default UFW creates rules for both IPv4 and IPv6 — this is controlled by the IPV6=yes parameter in /etc/default/ufw. If the server has an IPv6 address but support is disabled, services on IPv6 may end up exposed without any filtering. Check that the output of ufw status includes lines marked (v6).

Application profiles

Packages of many services install profiles listing their ports. List available profiles and an example of usage:

sudo ufw app list
sudo ufw allow "OpenSSH"
sudo ufw allow "Nginx Full"

A profile is convenient because it opens exactly the ports the service needs without manual enumeration.

Docker bypasses UFW

The main trap on servers with containers. Docker documentation states plainly: when you publish a container port, traffic to it is forwarded before it is seen by UFW rules, and Docker is incompatible with UFW in this sense. The -p 5432:5432 line in docker run or ports: - "5432:5432" in Compose makes the database accessible from the internet even if the port is closed in UFW.

What to do about this:

• publish service ports only on the local address: -p 127.0.0.1:5432:5432, and expose the service externally via a reverse proxy;
• use a shared Docker network for inter-container communication and do not publish the port at all;
• if you still need to open the port to the outside with restrictions, add rules to the DOCKER-USER chain, which Docker checks before its own rules;
• after deployment, check open ports from the outside, for example from another server using nmap.

Logging

To see dropped connections, enable logging:

sudo ufw logging on

Entries go to the system journal with the tag [UFW BLOCK]. On a server exposed to the internet there will be many — it’s the background constant scanning, not a targeted attack on you personally.

When UFW is not enough

UFW handles typical single-server tasks well. For complex routing, NAT between multiple networks, or fine-grained work with address sets, it’s more convenient to write nftables rules directly. Do not mix manual nftables rules and UFW on the same server: it will be hard to figure out which rule fired.

Common mistakes

• UFW enabled without an SSH rule — server access is lost.
• A deny rule is placed below an allow rule and does not take effect.
• IPv6 is disabled in UFW while services listen on IPv6.
• Container ports are published on all interfaces and exposed to the internet bypassing UFW.
• A port was opened “for debugging” and forgotten.

A firewall is only the first layer. What else to do with a new server is collected in the checklist “Bought a VPS — what’s next?” and in the article “A new server is not a blank slate”.