A host firewall decides which network traffic is allowed to reach services on your server. The principle is easy to state: allow only what you intend to expose, and block the rest. The practice is where people lock themselves out, so the order of operations matters as much as the rules.

Why Run a Host Firewall at All

If your provider offers a network-level firewall or security group, you might wonder whether a firewall on the server is redundant. It is not. The two protect at different layers and fail differently. A provider firewall might be misconfigured, shared among many servers, or bypassed by traffic from inside your private network. A host firewall is the last line of defense and travels with the machine. Using both is a sound layered approach.

It also acts as a safety net against your own mistakes. A database accidentally listening on all interfaces is much less alarming when the firewall only permits connections from your application servers.

The Mental Model

Linux packet filtering is performed in the kernel by the netfilter framework. You normally interact with it through a front end. Common ones:

• ufw (Uncomplicated Firewall), a simple front end, popular on Debian and Ubuntu systems.
• firewalld, used by default on Red Hat family distributions, which organizes rules into zones.
• nftables, the modern rule language and tool that has been replacing the older iptables; many front ends sit on top of it.

Which you use matters less than using one consistently. Mixing several tools managing the same rules leads to surprises, so choose one per server and document it.

All of them express the same ideas:

1. Default policy. What happens to traffic that matches no rule. For incoming traffic on a server, the safe default is deny.
2. Rules. Exceptions that allow specific traffic: a port, a protocol, optionally a source address range.
3. Direction. Incoming, outgoing and forwarded traffic are handled separately. Most servers focus on restricting incoming, though restricting outgoing can limit damage after a compromise, at the cost of more maintenance.
4. Statefulness. The firewall tracks connections, so replies to traffic you initiated are allowed back in without a rule for each.

The Safe Order of Operations

The classic mistake is turning on a default-deny policy before allowing SSH. The firewall comes up, your session may drop, and you are locked out of a remote machine. Follow this order:

1. Inventory what is listening. Use ss -tulpn to list listening sockets and their processes. This tells you what you need to allow, and what should not be listening at all.
2. Allow your management access first, ideally restricted to known source addresses if you have stable ones.
3. Allow the services you intentionally expose, such as web ports.
4. Set the default incoming policy to deny.
5. Enable the firewall, and before closing your current session, open a second session to prove you can still log in.
6. Make rules persistent so they survive a reboot, and confirm how your chosen tool does this.

On a cloud or virtual machine, know your recovery path before experimenting: a web console, serial console or rescue mode from your provider. Test firewall changes where you have such a fallback, and avoid risky changes on a machine you can only reach over SSH with no alternative.

Rules That Age Well

• Prefer narrow rules. Allow a database port only from the application servers, not from anywhere.
• Name or comment rules so future readers know why each exists. Many tools support comments.
• Avoid exposing admin interfaces like database ports and dashboards to the public internet; reach them through a VPN or SSH tunnel instead.
• Handle IPv6 deliberately. If the server has an IPv6 address, rules that only cover IPv4 leave the other protocol open. Confirm your tool covers both.
• Be careful with containers. Container runtimes often manipulate firewall rules themselves, and published ports can bypass rules you thought applied. Check how your container platform interacts with your firewall in its current documentation.

What Each Layer Is Good For

Layer	Strength	Weakness
Provider firewall or security group	Blocks traffic before it reaches the host	Coarse, may be shared, may not cover internal traffic
Host firewall	Travels with the machine, fine-grained	Misconfiguration can lock you out; per-server upkeep
Service configuration (bind addresses)	Prevents exposure at the source	Easy to change accidentally
Network segmentation	Limits blast radius	More design effort

A Realistic Example

A new server runs a web application and a database on the same host. The administrator lists listening sockets and finds the web server on the public ports, SSH on its port, and the database listening on all interfaces, which it should not be. They first change the database to listen only on the local interface. Then they allow SSH from the office address range, allow the two web ports from anywhere, set the default incoming policy to deny, enable the firewall and open a second SSH session to confirm access before logging out of the first. Finally they save the rules, reboot in a maintenance window to verify the rules persist, and record the setup in their runbook.

Frequently Asked Questions

Is a firewall necessary if all my services require passwords? Yes. A firewall reduces the attack surface by hiding services that need not be reachable at all, which protects against vulnerabilities as well as weak credentials.

Should I use ufw, firewalld or nftables? Use the one your distribution favors and your team understands, and avoid managing the same rules with several tools. They all rely on the kernel’s packet filtering underneath.

How do I avoid locking myself out over SSH? Allow SSH before enabling a default-deny policy, keep a second session open while testing, and know your provider’s console recovery option.

Do I need to block outgoing traffic too? Not always. Egress filtering can limit damage after a compromise but requires more maintenance. Many small setups start with incoming rules and add outgoing restrictions where risk justifies them.

Why is a port still reachable even though my firewall blocks it? Common reasons: IPv6 not covered, a container runtime adding its own rules, rules in a different table or tool than you expected, or an upstream device forwarding traffic. Inspect the active ruleset and test from outside.

Next Step

Run ss -tulpn on one of your servers and compare the output to what you believe is exposed. Close or rebind anything unexpected, then confirm from an external machine that only the intended ports answer.