Packet filtering in Linux - iptables, nftables and firewalld

Posted on July 9, 2021 by Adrian Wyssmann ‐ 8 min read

Packet filtering is essential for network security and Linux offers this out of the box. There are different possibilities like iptables, nftables or firewalld, and a basic understanding of these is very useful.

What is ip and packet filtering

An IP Filter operates mainly in layer 2 of the TCP/IP reference stack but can also work on layer 3. It usually filter packets based on their IP headers (Source and Destination address, TOS/DSCP/ECN, TTL, Protocol, etc.). The iptables-tutorial has some examples of how such headers look like. If you want to know more, you may also check the respective rfc, which goes into more details.

Netfilter, iptables and nftables

The netfilter project is an open source project for packet filtering on Linux:

The netfilter project enables packet filtering, network address [and port] translation (NA[P]T), packet logging, userspace packet queueing and other packet mangling.

In order for Linux to take advantage of it, the kernel has to be compiled with certain configurationseabled. A detailed example for iptables can be found in their documentation. I would say a lot of distributions come with that already built-in into the kernel they ship.

The project consist of two software pieces:

  • iptables is an IP filter that allows you to define rulesets. Each rule within an IP table consists of a number of classifiers (iptables matches) and one connected action (iptables target).
    • It also can filter packages based on other headers that lie deeper into the packet (TCP, UDP, etc), and shallower (MAC source address).
    • Connection tracking: It does keep track of packets and see if they are of the same stream (via sequence numbers, port numbers, etc.).
    • It is able to do Destination and Source Network Address Translation (generally called DNAT and SNAT)
    • It is able to do matching of packets
    • It can not connect data from different packets to each other (per default), and hence you can never be fully certain that you will see the complete data at all times.
  • nftables is the successor of iptables, with a completely new codebase and much improvements. It also uses a different syntax and a different command line utility than iptables. It is available in Linux kernels >= 3.13.
    • Compatibility layer that allows you to run iptables commands over the new nftables kernel framework
    • Faster packet classification through enhanced generic set and map infrastructure.
    • Simplified dual stack IPv4/IPv6 administration, through the new inet family that allows you to register base chains that see both IPv4 and IPv6 traffic
    • Better dynamic ruleset updates support.
    • Provide a Netlink API for third party applications, just as other Linux Networking and Netfilter subsystem do.
    • Address syntax inconsistencies and provide nicer and more compact syntax.

Looking at the OSI model a packet will enter the firewall on a wire (or well radio wave). It would then travel up to the proper device driver in the kernel. Then the packet starts to go through a series of steps in the kernel, before it is either sent to the correct application (locally), or forwarded to another host - or whatever happens to it. The netfilter has hooks - well-defined points in a packet’s traversal of the protocol stack - at which the software “hooks in”

nf hooks
packet flows through Linux networking (c) https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks

See also Traversing of tables and chains or some of other diagrams which gives you more detailslinux-ip-diagrams, Netfilter-IPTables-Diagrams.

iptables

iptables uses the netfilter infrastructure mentioned above. Let’s have a look at the Terms and Expressions to better understand how it works:

  • Drop/Deny - Package is deleted and no reply is sent back, nor receiver is notified

  • Reject - Same as drop but the sender is notified about the dropped package. There is no functionality to also send a packet notifying the receiving host of the rejected packet what happened.

  • State - A specific state of a packet in comparison to a whole stream of packets. States are known through the connection tracking system, which keeps track of all the sessions. See the state machine for details about states.

  • Chain - A chain contains a ruleset of rules that are applied on packets that traverses the chain. Each chain has a specific purpose (e.g., which table it is connected to, which specifies what this chain is able to do), as well as a specific application area (e.g., only forwarded packets, or only packets destined for this host). You may check rc.firewall file to get a better understanding of chains.

    Each table has some built-in chains e.g. table filter has PREROUTING, INPUT, OUTPUT, FORWARD and POSTROUTING.

    • prerouting: all newly-arrived IP traffic
    • input: traffic addressed to the local host itself
    • output: traffic originating from the local host itself
    • forward: packets the host is asked to simply pass from one network to another
    • postrouting: all IP traffic leaving the firewall
  • Table - There are 4 tables, each with a specific purpose:

    • raw: Only used for set a mark on packets that they should not be handled by the connection tracking system.
    • nat: Should only be used for NAT (Network Address Translation) on different packets i.e. translate the packet’s source field or destination field.
    • mangle: Used for mangling packets e.g. to change TOS (Type Of Service), TTL, MARK, …
    • filter: Used for filtering packages.
  • Match - This word can have two different meanings:

      1. A single match that tells a rule that this header must contain this and this information (e.g. source address must be a specific network range or host address)
      1. If the packet matches the whole rule, the jump or target instructions will be carried out (e.g., the packet will be dropped)
  • Target - A target set for each rule in a ruleset. If the rule has matched fully, the target specification tells us what to do with the packet. See Iptables targets and jumps for more details.

  • Rule - A rule is a set of a match or several matches together with a single target.

  • Ruleset - A ruleset is the complete set of rules that are put into a whole IP filter implementation.

  • Jump - A jump instruction tells ipdtables, to send the packet to another chain, to be processed. See Iptables targets and jumps for more details.

  • Connection tracking - A firewall which implements connection tracking is able to track connections/streams simply put.

  • Accept - To accept a packet and to let it through the firewall rules.

  • Policy - There are two kinds of policies that we speak about most of the time when implementing a firewall.

      1. Chain policies: Tells the firewall implementation the default behavior to take on a packet if there was no rule that matched it.
      1. Security policy: Documents to have thought through properly and to study properly before starting to actually implement the firewall

nftables

nftables uses the same Netfilter infrastructure as legacy iptables but with a new packet classification system. Here are the most significant changes over [iptabels]:

  • nftables uses a new, compact syntax inspired by tcpdump

  • Tables and chains are fully configurable and no pre-defined tables or chains

  • A single nftables rule can take multiple actions

  • New generic set infrastructure that allows advanced configurations such as maps, verdict maps and intervals to achieve performance-oriented packet classification.

  • Better support for dynamic ruleset updates

  • Support new protocols without a kernel upgrade.

  • Support for concatenations.

  • nftables enables filtering on different levels which are abstracted into families - in iptables there is a separate tool for each level:

    • ip: Tables of this family see IPv4 traffic/packets.
    • ip6: Tables of this family see IPv6 traffic/packets.
    • inet: Tables of this family see both IPv4 and IPv6 traffic/packets, simplifying dual stack support.
    • arp: Tables of this family see [ARP](https://en.wikipedia.org/wiki/Address_Resolution_Protocol-level (i.e, L2) traffic, before any L3 handling is done by the kernel.
    • bridge: Tables of this family see traffic/packets traversing bridges (i.e. switching).
    • netdev: The netdev family is different from the others in that it is used to create base chains attached to a single network interface i.e. all network traffic on that interface.

Firewalld

There are a lot of user interfaces available to manage iptables or nftables. One of the most prominent and one that comes pre-installed and as a default firewall management tool is firewalld. It is the default for

  • RHEL 7 and newer
  • CentOS 7 and newer
  • Fedora 18 and newer
  • SUSE 15 and newer
  • OpenSUSE 15 and newer

Firewalld provides a dynamically managed firewall with support for network/firewall zones that define the trust level:

  • Complete D-Bus API
  • IPv4, IPv6, bridge and ipset support
  • IPv4 and IPv6 NAT support
  • Firewall zones
  • Predefined list of zones, services and icmptypes
  • Simple service, port, protocol, source port, masquerading, port forwarding, icmp filter, rich rule, interface and source address handlig in zones
  • Simple service definition with ports, protocols, source ports, modules (netfilter helpers) and destination address handling
  • Rich Language for more flexible and complex rules in zones
  • Timed firewall rules in zones
  • Simple log of denied packets
  • Direct interface
  • Lockdown: Whitelisting of applications that may modify the firewall
  • Automatic loading of Linux kernel modules

Thanks to the D-Bus interface, changes can be done immediately in the runtime environment, without restart of the service or daemon. It has core layer which handles the configuration and the back ends like iptables, ip6tables, ebtables, ipset and the module loader. On top of the core there is the D-Bus layer, which is the primary way to alter and create the firewall configuration using the provided tools:

firewalld concept
firewalld structure