The VikiD Truth

Knowledge base / Computing / Security

Picolisp | Picolisp Machine | Pil Sources | Linux | BASH | C-Programmming | Operating Systems | Javascipt | Emacs | vim | Pharo Smalltalk | Computer Security | Python | The Compiler | Identifiers | Literals | storage_linkage | Firewalls

Packet Filtering Firewalls

Filters Traffic works on layer 2-3

The plain idea

A packet-filtering firewall looks at each packet’s envelope, not the letter inside. For every packet it reads a few header fields, the source and destination IP address, the protocol (TCP, UDP, ICMP) and the port numbers, and compares them against an ordered list of rules. The first rule that matches decides: allow or drop. If nothing matches, the default policy applies, and on any sensible firewall that default is “deny”.

Strictly speaking this works at layer 3 (IP addresses) and layer 4 (ports), with some filters also able to match layer-2 details such as MAC addresses. It is the oldest kind of firewall, dating from the late 1980s, and it is still built into every router, every cloud security group and the Linux kernel itself (netfilter, configured today with nft, or through friendlier front ends such as ufw and firewalld).

Why it matters

Packet filtering is cheap and fast enough to run on every interface of every device. It cuts away most of the internet’s noise before anything else has to think about it: if your server only offers SSH and HTTPS, there is no reason for a packet aimed at port 3389 to reach it at all. Every more sophisticated firewall type described on these pages still starts with this step.

An everyday analogy: the gated estate

A guard at an estate gate checks the address on each delivery van: “Number 12? You’re on the list. Number 40? No such house, turn around.” He never opens the parcels. That makes him quick, and it also means a dangerous parcel addressed correctly sails straight through.

A worked example: a home server with nftables

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    iif lo accept                         # local traffic
    ct state established,related accept   # replies to my own connections
    tcp dport { 22, 443 } accept          # SSH and HTTPS
    icmp type echo-request limit rate 5/second accept
  }
}

The same policy with ufw is three lines: ufw default deny incoming, ufw allow 22/tcp, ufw allow 443/tcp, then ufw enable. Read the rules from top to bottom: a packet to port 443 hits the third rule and is accepted; a packet to port 23 (telnet) matches nothing and falls to policy drop. Note the ct state line: strictly that is stateful filtering, covered on the stateful firewall page, and in practice every modern packet filter uses it.

Common misconceptions

How it connects

Packet filtering is the base layer. Stateless and stateful firewalls describe whether it remembers connections; circuit-level gateways, application proxies and next-generation firewalls climb higher up the network stack. See the overview at Firewalls.

The truth revealed: a packet filter is a bouncer who checks names on a list. Essential, but never the whole of security.

Types of Firewalls

UFW

The Uncomplicated Firewall (ufw) is a friendly front end for the Linux kernel firewall (netfilter; nftables underneath on current distributions) and is particularly well suited for host-based firewalls.

Last edited · 3 revisions

Tags: #Computing