Blog

Most Linux servers sit behind a network firewall and, too often, stop there. Yet a network firewall cannot inspect traffic that never crosses it, and it tends to trust everything already inside. A host firewall – one running on the server itself – closes that gap. Configured well, a Linux firewall enforces a single, powerful rule: this machine accepts only the connections it genuinely needs. Everything else is refused at the door, quietly and by default.

Why a Linux firewall matters

Perimeter defences assume the threat sits outside, but reality is far messier than that. A compromised workstation, a rogue device or a misconfigured neighbour can all reach your server from within the trusted network. Because a host firewall applies wherever traffic originates, it limits lateral movement when something inside does go wrong. In effect, each server then defends itself, rather than leaning wholly on the boundary to hold the line. For example, ransomware that lands on one machine will happily probe every neighbour it can reach, and a tight host firewall is precisely what stops that probe cold. Moreover, cloud and container estates multiply the number of hosts, so a per-host rule set scales where a single perimeter simply cannot. Think of it as internal segmentation applied at the smallest possible unit.

Default deny is the whole idea

One principle underpins everything else: deny by default, and then allow only what is required. Start by refusing all inbound traffic, and open ports one at a time as services actually need them. This inverts the usual accident, where a forgotten service sits exposed simply because nobody ever closed it. By contrast, an allow-by-default posture leaves you permanently guessing about what is currently open. In practice, you will also discover services you had forgotten were running, which is a useful audit in itself. Outbound traffic deserves the same scrutiny, though administrators neglect it far more often, as we will see shortly.

The tools you will meet

Modern distributions offer a handful of front ends to the same underlying kernel machinery:

• nftables is the current native framework, and it replaces the older iptables with cleaner, more consistent syntax.
• firewalld adds a zone-based abstraction, handy on Red Hat family systems and for rule changes made without dropping live connections.
• ufw offers a deliberately simple front end, common on Debian and Ubuntu servers.

Choose one, and then use it consistently. Mixing tools on the same host invites confusion, and it breeds rules that quietly contradict one another. Whichever you pick, the concepts carry across, because all three ultimately drive the same netfilter core inside the kernel.

Do not forget outbound

Inbound rules attract nearly all the attention, yet egress filtering is where a host firewall earns its keep during an incident. Malware routinely needs to call home, fetch a second-stage payload, or push stolen data back out. Consequently, a server allowed to reach only a package mirror and a logging host is far less useful to an attacker than one permitted to talk to anything at all. Consider a database server: it may legitimately need to reach almost nothing beyond its backups and its updates, so a tight egress policy costs little and gains a great deal. Egress rules take real effort to get right, admittedly. Still, they turn a compromise into a contained nuisance rather than an open door. Similarly, a locked-down server that suddenly tries to reach an unknown address becomes an obvious warning in your logs.

Test, log and persist

A firewall you cannot see is a firewall you cannot trust. Log dropped traffic, at least while you tune the rules, so that you can tell a genuine block from a broken service. Confirm that the ruleset survives a reboot, because an unsaved configuration is a false sense of safety. A rule that works today but vanishes at the next restart has quietly protected nothing, and you will not notice until an incident proves the point. Furthermore, a short comment beside each rule later explains why the exception exists, which spares a future headache. Above all, test from another machine: scan the server, and check that only the intended ports answer.

Where to start

Take one server, and write its rules from a clean slate. Deny everything, permit SSH from your admin network, add the handful of services the box must offer, and constrain outbound traffic to known destinations. Verify the result from outside, save the ruleset, and capture it as a template. From then on, every new build inherits a sensible baseline instead of an open one. Ultimately, the aim is a baseline so ordinary that an exposed server looks obviously wrong at a glance. None of this demands exotic tooling; it demands only the discipline to start closed and open up deliberately.

Halkyn Consulting helps organisations build and review secure Linux estates, from a single server to a fleet-wide standard. If you would like support hardening your systems, get in touch with our team.