| Message ID | 20201013113857.12117-1-pablo@netfilter.org |
|---|---|
| State | Accepted |
| Delegated to: | Pablo Neira |
| Headers | show |
| Series | [nft] src: ingress inet support | expand |
On 2020-10-13 13:38, Pablo Neira Ayuso wrote: > Add support for inet ingress chains. > > table inet filter { > chain ingress { > type filter hook ingress device "veth0" priority filter; policy accept; > } > chain input { > type filter hook input priority filter; policy accept; > } > chain forward { > type filter hook forward priority filter; policy accept; > } > } This sound interesting, thanks. I could see some questions coming from users: * where are the docs on which packet/traffic sees this nft family vs netdev? * what are the added benefit of this nft family vs netdev? * is the netdev family somehow deprecated? regards.
Hi Arturo, On Wed, Oct 14, 2020 at 05:54:13PM +0200, Arturo Borrero Gonzalez wrote: > On 2020-10-13 13:38, Pablo Neira Ayuso wrote: > > Add support for inet ingress chains. > > > > table inet filter { > > chain ingress { > > type filter hook ingress device "veth0" priority filter; policy accept; > > } > > chain input { > > type filter hook input priority filter; policy accept; > > } > > chain forward { > > type filter hook forward priority filter; policy accept; > > } > > } > > This sound interesting, thanks. > > I could see some questions coming from users: > > * where are the docs on which packet/traffic sees this nft family vs netdev? > * what are the added benefit of this nft family vs netdev? See patch update for documentation, let me know if this addresses these two questions. I can extend it further, let me know. > * is the netdev family somehow deprecated? I don't think so. The netdev family is still useful for filter packet of any possible ethertype that are entering through a given device (for instance ARP, 802.1q, 802.1ad among others). The only difference between inet ingress and netdev ingress is that the sets and maps that are defined in a given inet table can be accessed from the ingress chain, note that it is not possible to access inet sets and maps from the netdev ingress chain. If your ruleset if focused on traffic filtering for IPv4 and IPv6, then inet ingress should be enough. The ingress netdev chain also comes with hardware offload support, which allows you to drop packets from the NIC, which might be useful in DoS scenarios to save CPU cycles. You only have to check if your NIC is supported.
On Wed, Oct 14, 2020 at 08:47:25PM +0200, Pablo Neira Ayuso wrote: > Hi Arturo, > > On Wed, Oct 14, 2020 at 05:54:13PM +0200, Arturo Borrero Gonzalez wrote: > > On 2020-10-13 13:38, Pablo Neira Ayuso wrote: > > > Add support for inet ingress chains. > > > > > > table inet filter { > > > chain ingress { > > > type filter hook ingress device "veth0" priority filter; policy accept; > > > } > > > chain input { > > > type filter hook input priority filter; policy accept; > > > } > > > chain forward { > > > type filter hook forward priority filter; policy accept; > > > } > > > } > > > > This sound interesting, thanks. > > > > I could see some questions coming from users: > > > > * where are the docs on which packet/traffic sees this nft family vs netdev? > > * what are the added benefit of this nft family vs netdev? > > See patch update for documentation, let me know if this addresses > these two questions. I can extend it further, let me know. > > > * is the netdev family somehow deprecated? > > I don't think so. The netdev family is still useful for filter packet > of any possible ethertype that are entering through a given device > (for instance ARP, 802.1q, 802.1ad among others). The only difference > between inet ingress and netdev ingress is that the sets and maps that > are defined in a given inet table can be accessed from the ingress > chain, note that it is not possible to access inet sets and maps from > the netdev ingress chain. > > If your ruleset if focused on traffic filtering for IPv4 and IPv6, > then inet ingress should be enough. > > The ingress netdev chain also comes with hardware offload support, > which allows you to drop packets from the NIC, which might be useful > in DoS scenarios to save CPU cycles. You only have to check if your > NIC is supported. Forgot attachment to update documentation, I can possibly include this information I mentioned above too.
On 2020-10-14 20:48, Pablo Neira Ayuso wrote: > Forgot attachment to update documentation, I can possibly include this > information I mentioned above too. Thanks, that would work!
diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h index 18075f958c8d..feb6287c5979 100644 --- a/include/linux/netfilter.h +++ b/include/linux/netfilter.h @@ -48,6 +48,7 @@ enum nf_inet_hooks { NF_INET_FORWARD, NF_INET_LOCAL_OUT, NF_INET_POST_ROUTING, + NF_INET_INGRESS, NF_INET_NUMHOOKS }; diff --git a/src/evaluate.c b/src/evaluate.c index 5f17d7501ac0..abbf83aef576 100644 --- a/src/evaluate.c +++ b/src/evaluate.c @@ -3965,10 +3965,12 @@ static uint32_t str2hooknum(uint32_t family, const char *hook) return NF_INET_NUMHOOKS; switch (family) { + case NFPROTO_INET: + if (!strcmp(hook, "ingress")) + return NF_INET_INGRESS; case NFPROTO_IPV4: case NFPROTO_BRIDGE: case NFPROTO_IPV6: - case NFPROTO_INET: /* These families have overlapping values for each hook */ if (!strcmp(hook, "prerouting")) return NF_INET_PRE_ROUTING; @@ -4042,7 +4044,9 @@ static int chain_evaluate(struct eval_ctx *ctx, struct chain *chain) expr_name(chain->policy)); } - if (chain->handle.family == NFPROTO_NETDEV) { + if (chain->handle.family == NFPROTO_NETDEV || + (chain->handle.family == NFPROTO_INET && + chain->hook.num == NF_INET_INGRESS)) { if (!chain->dev_expr) return __stmt_binary_error(ctx, &chain->loc, NULL, "Missing `device' in this chain definition"); diff --git a/src/rule.c b/src/rule.c index d75b36c4eb0d..4719fd6158f2 100644 --- a/src/rule.c +++ b/src/rule.c @@ -1019,6 +1019,8 @@ const char *hooknum2str(unsigned int family, unsigned int hooknum) return "postrouting"; case NF_INET_LOCAL_OUT: return "output"; + case NF_INET_INGRESS: + return "ingress"; default: break; }; diff --git a/tests/shell/testcases/chains/0043chain_ingress_0 b/tests/shell/testcases/chains/0043chain_ingress_0 new file mode 100755 index 000000000000..79cd5208f2dc --- /dev/null +++ b/tests/shell/testcases/chains/0043chain_ingress_0 @@ -0,0 +1,18 @@ +#!/bin/bash + +set -e + +RULESET="table inet filter { + chain ingress { + type filter hook ingress device \"lo\" priority filter; policy accept; + } + chain input { + type filter hook input priority filter; policy accept; + } + chain forward { + type filter hook forward priority filter; policy accept; + } +}" + +$NFT -f - <<< "$RULESET" && exit 1 +exit 0 diff --git a/tests/shell/testcases/chains/dumps/0043chain_ingress.nft b/tests/shell/testcases/chains/dumps/0043chain_ingress.nft new file mode 100644 index 000000000000..74670423fc84 --- /dev/null +++ b/tests/shell/testcases/chains/dumps/0043chain_ingress.nft @@ -0,0 +1,11 @@ +table inet filter { + chain ingress { + type filter hook ingress device \"lo\" priority filter; policy accept; + } + chain input { + type filter hook input priority filter; policy accept; + } + chain forward { + type filter hook forward priority filter; policy accept; + } +}
Add support for inet ingress chains. table inet filter { chain ingress { type filter hook ingress device "veth0" priority filter; policy accept; } chain input { type filter hook input priority filter; policy accept; } chain forward { type filter hook forward priority filter; policy accept; } } Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> --- include/linux/netfilter.h | 1 + src/evaluate.c | 8 ++++++-- src/rule.c | 2 ++ .../shell/testcases/chains/0043chain_ingress_0 | 18 ++++++++++++++++++ .../chains/dumps/0043chain_ingress.nft | 11 +++++++++++ 5 files changed, 38 insertions(+), 2 deletions(-) create mode 100755 tests/shell/testcases/chains/0043chain_ingress_0 create mode 100644 tests/shell/testcases/chains/dumps/0043chain_ingress.nft