Using a firewall on your Linux server

A firewall on the server decides which of its ports answer at all. Debian and Ubuntu use ufw, the RHEL family uses firewalld, and both are front ends for the same packet filter underneath, so run one of them and not both.

Find out what is already running

systemctl is-active ufw firewalld

Debian and Ubuntu images ship ufw installed but inactive. RHEL, Alma, and Rocky images usually ship firewalld installed and running. Install the missing one only if you have neither:

apt install -y ufw

dnf install -y firewalld
systemctl enable --now firewalld

The common cases, side by side

Note the range separator differs: ufw wants a colon, firewalld wants a hyphen.

ufw, on Debian and Ubuntu

Set the policy and the SSH rule before you enable anything:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw enable

ufw enable warns that the command may disrupt existing SSH connections and asks for confirmation. That warning is the reason the SSH rule goes first.

A game server usually needs the same port on both protocols, and each protocol is a separate rule:

ufw allow 30120/tcp
ufw allow 30120/udp

Restrict a management port to one address rather than opening it to everyone:

ufw allow from 203.0.113.10 to any port 22 proto tcp

To slow down repeated connection attempts on a port, ufw limit 22/tcp denies an address that opens too many connections in a short window. Run man ufw for the exact thresholds your version uses.

Listing and removing

ufw status numbered

Delete by the number shown, or by repeating the rule:

ufw delete 3
ufw delete allow 30120/udp

Deleting by number renumbers everything below it, so re-run ufw status numbered between deletions rather than working down a list you printed earlier.

firewalld, on RHEL, Alma, and Rocky

firewalld sorts interfaces into zones, and the default zone for a server is normally public. Check what you are working on:

firewall-cmd --get-default-zone
firewall-cmd --list-all

The public zone already refuses inbound traffic that is not explicitly allowed, so there is no default-deny command to run. What you add is the list of exceptions:

firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-port=30120/tcp
firewall-cmd --permanent --add-port=30120/udp
firewall-cmd --reload

--permanent writes the rule to disk but does not apply it until the reload. Without --permanent the rule applies immediately and is lost at the next reload or reboot. Run a change one way, confirm it, then commit what is live:

firewall-cmd --runtime-to-permanent

Allowing a single source needs a rich rule:

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10" port port="22" protocol="tcp" accept'
firewall-cmd --reload

Listing and removing

firewall-cmd --list-all
firewall-cmd --list-ports
firewall-cmd --list-services
firewall-cmd --permanent --remove-port=30120/udp
firewall-cmd --reload

Testing a rule that might cut you off

firewalld can add a rule that expires on its own, which is the safest way to try a change to a port you depend on:

firewall-cmd --add-port=2222/tcp --timeout=5m

--timeout cannot be combined with --permanent: the rule is runtime only, and after five minutes it disappears whether or not you are still connected. ufw has no equivalent, so there the discipline is a second session and the console.

Two things that catch people out

Docker publishes ports past ufw. A container started with -p 30120:30120 is reachable from the internet even when ufw denies that port, because Docker inserts its own forwarding rules ahead of ufw's. If a port should only be reachable from the host, publish it to loopback instead, with -p 127.0.0.1:30120:30120. If it should not be reachable at all, close it somewhere Docker does not rewrite, which includes the panel.

Check what is listening before you decide what to allow. A service bound to 0.0.0.0 is reachable the moment a rule opens its port, including ones you forgot were installed:

ss -tulnp

How this relates to Clouduxe protection

Your host firewall and the rules on the Firewall tab in the panel are not two versions of the same thing. They sit at different points in the path, and they know different things.

They act at different points

A packet aimed at your server meets the panel's rules first. If a rule there drops it, ufw and firewalld never see it, and neither does the service. If your host firewall drops it, the packet has already arrived: it crossed the network, reached the machine, and cost it the work of looking at it and deciding.

For one packet that difference does not matter. For a flood it is the entire difference, which is why a source you want gone is better blocked in the panel than with a ufw deny rule. See Blocking and allowing IPs.

They cover different ground

The host firewall sees things the panel does not: loopback, individual interfaces, outbound traffic, container bridges, and every local service that is listening whether you meant it to be or not. It is also where you express rules about traffic that never leaves the machine.

The panel's rules carry what a host firewall has no notion of: packet-rate ceilings per port, whether traffic arriving on a port speaks the protocol the service actually speaks, and per-source allow and deny lists that apply before the traffic lands. How protection works sets out what runs where.

Neither replaces the other. A host firewall does not defend against a flood: it decides what is reachable, it does not reduce what arrives. Protection in the panel is not a reason to leave a database or a management port listening on a public address, because a rate ceiling does not make an open service safe.

Keep the two lists in agreement

For a port to be usable it has to be allowed in both places. When players cannot connect, that is the first thing to check: the rule exists in the panel, and the host firewall is not denying the same port. The number of rules the panel accepts is finite, so plan them per service rather than per player; see Port rules.

Related