Kahibaro

Discord Login Register ☰

Firewalls in depth

Table of Contents

Understanding Linux Firewall Architecture

Linux offers multiple layers where firewalling can occur. For advanced administration you need to understand how these pieces fit together:

Netfilter – The packet filtering framework built into the Linux kernel.
iptables / ip6tables / arptables / ebtables – Legacy user-space tools to configure Netfilter.
nftables – The modern replacement for iptables, also talking to Netfilter.
Front-ends / controllers – Higher-level tools:

firewalld (zone-based, dynamic)
ufw/gufw (Ubuntu-focused)
Distribution-specific wrappers (e.g., SuSEfirewall2 historically)

In depth firewall work usually means:

Knowing what your front-end is doing under the hood.
Being able to bypass or replace the front-end when needed.
Understanding packet flow through Netfilter chains.

Netfilter Packet Flow in Detail

The kernel checks packets at several hook points. For IPv4, the classic iptables chains correspond to these hooks:

PREROUTING – Before routing decision.
INPUT – Packets destined to the local machine.
FORWARD – Packets being routed through (not for local processes).
OUTPUT – Locally generated packets.
POSTROUTING – After routing, before the packet actually leaves.

Conceptually, a packet from outside to a local service flows like:

NIC receives packet
raw table PREROUTING (optional)
mangle table PREROUTING
nat table PREROUTING
Routing decision: is this packet for us or to be forwarded?
If for us:

mangle table INPUT
filter table INPUT
Delivered to local socket

If forwarded:

mangle table FORWARD
filter table FORWARD
mangle table POSTROUTING
nat table POSTROUTING
Outgoing NIC

For outgoing packets generated by the host:

Local process creates packet
raw table OUTPUT
mangle table OUTPUT
nat table OUTPUT
Routing decision
mangle table POSTROUTING
nat table POSTROUTING
Outgoing NIC

Understanding this flow is crucial for advanced tasks like:

Debugging why NAT isn’t working.
Ensuring marking/mangling occurs at the right point.
Designing policies for a server that also acts as a router/firewall.

Tables, Chains, and Targets

Netfilter is organized into tables. Each table has chains (hooks), and each chain has rules with matches and targets.

Common tables (iptables/nftables concepts apply, though syntax differs):

filter – Main table for allow/deny of packets.
nat – For address translation (SNAT, DNAT, MASQUERADE).
mangle – For altering packet headers, TOS/DSCP, marks, etc.
raw – For connection tracking exemptions and very early matching.
security – For use with LSM (SELinux, AppArmor) in some setups.

Common targets/actions:

ACCEPT – Stop traversing the current chain, accept the packet.
DROP – Silently discard the packet.
REJECT – Actively reject, optionally sending ICMP/TCP error.
LOG – Log packet info then continue traversing.
RETURN – Stop current user chain, return to caller chain.
NAT-specific: SNAT, DNAT, MASQUERADE, REDIRECT.

Deep firewall design often mixes:

filter table for security policy.
nat table for address translation.
mangle table for QoS/marks/advanced routing.

Stateful Firewalls and Connection Tracking

Linux firewalls are stateful by default using the connection tracker (conntrack):

New connection is classified as NEW.
Established flows become ESTABLISHED.
Reverse-direction packets are RELATED or ESTABLISHED.
Packets not matching any known flow are INVALID.

You can match connection state (iptables) with:

Views: 24

Comments

Please login to add a comment.

Don't have an account? Register now!