ufw and firewalld

ufw and firewalld are front-ends that help you manage the Linux firewall on a server you control. Underneath, they talk to nftables, or to iptables on older images. You set a default policy, allow the ports you need, and then enable the firewall. On LogicWeb shared hosting you do not run either tool, because the node already handles that layer. This guide is for a VPS or dedicated server where you have root access.

Choose a deny-by-default policy

The usual starting point is incoming deny, outgoing allow, and routed deny. In ufw you write that as default deny incoming. firewalld reaches a similar place with the drop or public zone. If you open incoming by default and then try to lock down with a few denies, it is easy to miss a port. Deny by default plus explicit allows is the model that holds up when you are tired.

Add rules in a safe order

Allow SSH first on port 22 for both IPv4 and IPv6. People often forget IPv6 and then cannot get back in from a dual-stack laptop, or they leave IPv6 wide open while IPv4 looks tight. Next allow HTTP and HTTPS on 80 and 443. After that, open only the app port you truly need from the outside. A database such as MariaDB on 3306 should bind to localhost instead of sitting open on the public interface, so you can skip a firewall hole for it.

ufw status verbose

That command prints the default policy, whether IPv6 is on, and every rule with its direction. Read the output after every change. If the status shows inactive, none of those rules are live yet, which can be either a relief or a surprise. The firewalld equivalent is firewall-cmd --list-all. Pick one front-end and stick with it. Running ufw and firewalld together is a fight, because enabling ufw can wipe a firewalld zone you thought was the source of truth.

Enable only when you already have a way back in

The classic lockout is ufw enable before SSH is allowed, before your key is in authorized_keys, or before the network path to port 22 is open. Enable from a session that already works, with 22 already allowed, and with a console path you have tested. On a dedicated server that path is often IPMI. A login banner and a changed SSH port are not a substitute for this checklist.

A short rule set you understand is safer than a large zone layout you have not read. After enable, run status again and test SSH from a second session before you close the first one.