Skip to content

Security

Firewalls: CSF, firewalld, nftables

Learn how CSF, firewalld, and nftables control which ports your VPS exposes to the internet.

Updated Aug 29, 20263 min read12 reads
Firewalls: CSF, firewalld, nftables
Host firewall basics with CSF, firewalld, and nftables

A host firewall is the rule set on your server that decides which ports the public internet can reach. CSF, firewalld, and nftables are three common ways to write those rules on a VPS. You choose one tool, allow only the ports you need, and leave everything else closed by default.

Allow SSH on port 22, or on the custom SSH port you actually use. Allow 80 and 443 for web traffic. Add 25, 587, or 465 only when you truly mean to send or receive mail. Turn the firewall on before you install applications, not after. If the box has IPv6 and AAAA records, write matching IPv6 rules too, because an IPv4-only policy on a dual-stack server leaves a gap.

See what is already listening

Before you open ports to the world, check what is bound on the server right now:

bash
ss -lntp

Each line shows a process and the port it is using. Ports 80 and 443 should belong to the web server. Port 22 should belong to sshd. MySQL listening on 0.0.0.0 on 3306 is almost never what you want; bind it to localhost instead. Redis on 0.0.0.0 is a common way outsiders gain a free replica. Treat this list as the map your firewall rules should match, not as a mystery to ignore.

Pick one firewall tool on purpose

CSF is the usual choice on cPanel and WHM servers, and you edit CSF so you are not fighting firewalld at the same time. firewalld is the default on many RHEL and AlmaLinux systems without WHM. On modern kernels, both tools ultimately talk to nftables. Pick a single writer for your rules and stick with it. Stacking CSF on top of firewalld on top of handmade nftables makes it hard to know which rule actually won.

On shared hosting, the node firewall is managed by us, and you should not expect to run your own nftables inside CageFS. On a VPS you have root, so the host firewall is yours to maintain. Cloud security groups in front of the VPS are an extra layer. They are not a reason to skip the firewall on the server itself.

Keep the allow list small

fail2ban and Imunify sit on top of a closed baseline. They ban noisy clients; they do not replace a closed MySQL port. If you have AAAA records, write the IPv6 allow list as carefully as the IPv4 one. Then leave the rules alone until you add a service you can name out loud.

On a cPanel VPS, CSF allow and deny files are the source of truth you should edit. On AlmaLinux without WHM, firewalld zones are the usual path, and a public zone with 22, 80, and 443 is a common shape. A Node listener on port 3000 is not public until you open it on purpose. Any provider security group in front must allow the same ports, or traffic will still drop at the edge even when the host firewall looks open.

Share

Send this article

Need someone else to do this? Send them the link — the commands are in the article.

Tagged

Was this article helpful?

Be the first to rate this article.