Difference between revisions of "Netfilter hooks"

From nftables wiki
Jump to navigation Jump to search
(Added reminder that nftables does not predefine any base chains.)
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
If you are familiar with Netfilter, don't worry, most of the infrastructure remains the same. ''nftables'' reuses the existing hook infrastructure, [http://people.netfilter.org/pablo/docs/login.pdf Connection Tracking System], NAT engine, logging infrastructure, userspace queueing and so on. Therefore, '''we have only replaced the packet classification framework'''.
''nftables'' uses mostly the same Netfilter infrastructure as legacy ''iptables''. The hook infrastructure, [http://people.netfilter.org/pablo/docs/login.pdf Connection Tracking System], NAT engine, logging infrastructure, and userspace queueing remain the same. '''Only the packet classification framework is new'''.


For those unfamiliar with Netfilter, we provide ASCII art to represent our hooks:
The following schematic shows packet flows through Linux networking:


                                              Local
                                            process
                                              ^  |      .-----------.
                    .-----------.              |  |      |  Routing  |
                    |          |-----> input /    \---> |  Decision |----> output \
--> prerouting --->|  Routing  |                        .-----------.              \
                    | Decision  |                                                    --> postrouting
                    |          |                                                    /
                    |          |---------------> forward ---------------------------
                    .-----------.


Basically, traffic flowing to the local machine in the input path see the prerouting and input hooks. Then, the traffic that is generated by local processes follows the output and postrouting path.
https://people.netfilter.org/pablo/nf-hooks.png


If you configure your Linux box to behave as router, do not forget to enable forwarding via:
 
Traffic flowing to the local machine in the input path sees the prerouting and input hooks. Then, the traffic that is generated by local processes follows the output and postrouting path.
 
If you configure your Linux box to behave as a router, do not forget to enable forwarding via:


  echo 1 > /proc/sys/net/ipv4/ip_forward
  echo 1 > /proc/sys/net/ipv4/ip_forward


And then, the packets that are not addressed to your local system will be seen from the forward hook. In summary, packets that are not addressed to local processes follow this path: prerouting, forward and postrouting.
Then packets that are not addressed to your local system will be seen from the forward hook. Such forwarded packets follow the path: prerouting, forward and postrouting.
 
In a major change from iptables, which predefines chains at '''every''' hook (i.e. ''INPUT'' chain in ''filter'' table), nftables predefines '''no''' chains at all. You must must explicitly create a [[Configuring_chains#Base_chain_hooks | base chain]] at each hook at which you want to filter traffic.
 


= Ingress hook =
= Ingress hook =


Since Linux kernel 4.2, Netfilter also comes with an ingress hook that you can use from nftables. So the big picture now look like this:
The ingress hook was added in Linux kernel 4.2. Unlike the other netfilter hooks, the ingress hook is attached to a particular network interface.
                                                         
 
                                  .-----------.           
You can use ''nftables'' with the ingress hook to enforce very early filtering policies that take effect even before prerouting. Do note that at this very early stage, fragmented datagrams have not yet been reassembled. So, for example, matching ip saddr and daddr works for all ip packets, but matching L4 headers like udp dport works only for unfragmented packets, or the first fragment.
                                  |          |-----> input ...
---> ingress ---> prerouting --->|  Routing  |
                                  | Decision  |
                                  |          |
                                  |          |-----> forward ...
                                  .-----------.


You can use this new ingress hook to filter traffic from Layer 2. This new hook comes before prerouting, so this allows you to enforce very early filtering policies. This new hook basically provides an alternative to '''tc''' ingress filtering. You still need tc for traffic shaping/queue management.
The ingress hook provides an alternative to ''tc'' ingress filtering. You still need ''tc'' for traffic shaping/queue management.

Revision as of 00:32, 12 February 2021

nftables uses mostly the same Netfilter infrastructure as legacy iptables. The hook infrastructure, Connection Tracking System, NAT engine, logging infrastructure, and userspace queueing remain the same. Only the packet classification framework is new.

The following schematic shows packet flows through Linux networking:


nf-hooks.png


Traffic flowing to the local machine in the input path sees the prerouting and input hooks. Then, the traffic that is generated by local processes follows the output and postrouting path.

If you configure your Linux box to behave as a router, do not forget to enable forwarding via:

echo 1 > /proc/sys/net/ipv4/ip_forward

Then packets that are not addressed to your local system will be seen from the forward hook. Such forwarded packets follow the path: prerouting, forward and postrouting.

In a major change from iptables, which predefines chains at every hook (i.e. INPUT chain in filter table), nftables predefines no chains at all. You must must explicitly create a base chain at each hook at which you want to filter traffic.


Ingress hook

The ingress hook was added in Linux kernel 4.2. Unlike the other netfilter hooks, the ingress hook is attached to a particular network interface.

You can use nftables with the ingress hook to enforce very early filtering policies that take effect even before prerouting. Do note that at this very early stage, fragmented datagrams have not yet been reassembled. So, for example, matching ip saddr and daddr works for all ip packets, but matching L4 headers like udp dport works only for unfragmented packets, or the first fragment.

The ingress hook provides an alternative to tc ingress filtering. You still need tc for traffic shaping/queue management.