Difference between revisions of "Netfilter hooks"
(Tightened up description of network flow diagram, added some comments about using ingress hook.) |
(Added reminder that nftables does not predefine any base chains.) |
||
| Line 2: | Line 2: | ||
The following schematic shows packet flows 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 | ||
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. | 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. | ||
| Line 12: | Line 14: | ||
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. | 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 = | ||
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:
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.