Difference between revisions of "Netfilter hooks"

From nftables wiki
Jump to navigation Jump to search
(add schematic to represent hooks (contributed by Francisco Javier Rodríguez López))
(Tightened up description of network flow diagram, added some comments about using ingress hook.)
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 the following schematic for the packet flow paths through Linux networking:
The following schematic shows packet flows through Linux networking:


https://people.netfilter.org/pablo/nf-hooks.png
https://people.netfilter.org/pablo/nf-hooks.png


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.
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 router, do not forget to enable forwarding via:
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.


= 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.
                                                         
                                  .-----------.           
                                  |          |-----> 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.
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.

Revision as of 01:34, 11 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.

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.

Retrieved from "http://wiki.nftables.org/wiki-nftables/index.php?title=Netfilter_hooks&oldid=661"