Linux Firewalls with nftables: Host-Based Network Security and Audit Strategy

1. Introduction

A Linux host firewall limits which network traffic can reach local services and what traffic local processes can send. Even inside a trusted network, host-based filtering reduces lateral movement and protects services that were never meant to be reachable from every segment. This article focuses on defensive administration, auditing, and authorized lab work. The objective is to understand the control, identify misconfiguration before it becomes an incident, and build a repeatable hardening process that can be applied across real Linux environments.

2. How It Works

nftables is the modern Linux packet-filtering framework and replaces many legacy iptables workflows. Rules are organized into tables, chains, hooks, priorities, and expressions. Administrators can filter by addresses, ports, interfaces, connection state, and many other attributes. Linux security is layered, so this control should be considered together with identity, filesystem permissions, service configuration, kernel policy, network segmentation, and centralized monitoring. A single command rarely tells the whole story; the effective security posture comes from how these layers interact.

3. The Security Problem

The biggest issue is not the firewall engine itself but policy drift: permissive default rules, forgotten test ports, services bound to all interfaces, or cloud/network controls that are assumed to replace host controls. A rule set that nobody can explain is also difficult to maintain safely. These weaknesses are often created gradually by troubleshooting, legacy migrations, vendor installation scripts, or temporary exceptions that later become permanent. A good security review therefore looks not only for obviously dangerous settings, but also for configuration that no longer has a clear owner or business justification.

4. How Attackers Abuse It

Attackers benefit from unnecessarily exposed services and unrestricted outbound connectivity. After compromise, open egress may allow command-and-control traffic, data exfiltration, or scanning of nearby systems. A host firewall can limit these options when designed around real application needs. In an authorized assessment, the goal is to demonstrate exposure safely and report the exact condition that creates the risk. In production incident response, avoid making destructive changes before collecting enough context to understand whether the issue is a simple misconfiguration, active abuse, or a persistence mechanism.

5. How to Detect / Enumerate & Audit It

Command

nft list ruleset

What it does: Display the complete nftables ruleset.

What to look for: Default accept policies, broad source ranges, and unexpected open ports.

Defensive use: Authoritative host-firewall review.

Command

ss -lntup

What it does: List listening TCP/UDP sockets and owning processes.

What to look for: Services listening on 0.0.0.0 or :: that should be local-only.

Defensive use: Compare exposure with firewall policy.

Command

nft list ruleset -a

What it does: List rules with handles.

What to look for: Rule handles useful for precise administration.

Defensive use: Support controlled rule changes.

Command

systemctl status nftables --no-pager 2>/dev/null

What it does: Check nftables service state on systems using the unit.

What to look for: Disabled persistence or load failures.

Defensive use: Verify the firewall survives reboot.

A useful operational habit is to save the output of these checks in a baseline for each server role. A database server, bastion host, developer workstation, and container node will not look identical, so comparison should be against a known-good peer or documented configuration rather than against a generic assumption.

6. How to Audit the Environment

• Document required inbound and outbound flows for each server role.
• Compare listening sockets with allowed firewall ports.
• Use default-deny principles where operationally feasible.
• Review IPv6 as well as IPv4; an IPv4-only policy may leave an unexpected path.
• Confirm rule persistence across reboot.
• Document every exception with an owner, reason, and review date.
• Re-check the control after upgrades because packages and deployment automation can silently change defaults.

7. How to Fix / Harden It

• Remove unused allow rules.
• Bind services to specific interfaces or localhost when remote access is unnecessary.
• Restrict management services to administrative networks.
• Use stateful rules and explicit exceptions rather than broad accepts.
• Treat outbound filtering as a risk-based control for high-value systems.
• Apply changes through configuration management when possible so the desired state is reproducible.
• Test hardening first on a staging host or a disposable snapshot and verify that critical services still function.

8. Detection & Monitoring

• Alert on firewall rule changes and unexpected service listeners.
• Detect new externally reachable ports after deployments.
• Correlate blocked connections with scanning or brute-force activity.
• Keep time synchronization reliable so host events can be correlated with firewall, identity, EDR, and SIEM data.
• Send high-value security logs off-host because a fully compromised root account can often alter local evidence.

9. MITRE ATT&CK Mapping

MITRE ATT&CK is most useful here as a common language for detection engineering and incident reporting. The mapping does not mean every misconfiguration is an active attack; it shows which attacker behaviors may become easier when the control is weak.

10. Practical Lab

In an isolated Linux lab or disposable VM:

1. Build a simple nftables policy in an isolated VM.
2. Allow SSH only from a lab management address and allow an application port from another test host.
3. Verify blocked and allowed traffic.
4. Reboot and confirm policy persistence.
5. Compare nft list ruleset with ss output.
6. Capture screenshots or command output before and after the change so you can prove what the control actually changed.
7. Revert the VM or remove the test configuration when finished.

11. Key Takeaways

• Linux Firewalls with nftables should be treated as part of a layered security model, not as an isolated setting.
• Inventory the current state first, because unknown configuration is difficult to secure.
• Prefer least privilege, explicit ownership, and documented exceptions.
• Monitor changes to the control itself; attackers often try to weaken defenses after gaining access.
• Test fixes in a lab and verify the effective runtime state, not only the configuration file.

Continue learning: Linux Security

This guide is part of our Linux Security series. Related guides in this series cover permissions, sudo, SUID/SGID, Linux capabilities, SSH, PAM, systemd, logging, firewalls, DNS, process security, filesystems, encryption, auditd, kernel hardening, containers, mandatory access control, package security, incident response, and backup protection.