Netfilter-Devel Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH nft] src: ingress inet support
@ 2020-10-13 11:38 Pablo Neira Ayuso
  2020-10-14 15:54 ` Arturo Borrero Gonzalez
  0 siblings, 1 reply; 5+ messages in thread
From: Pablo Neira Ayuso @ 2020-10-13 11:38 UTC (permalink / raw)
  To: netfilter-devel

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

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;
+	}
+}
-- 
2.20.1


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH nft] src: ingress inet support
  2020-10-13 11:38 [PATCH nft] src: ingress inet support Pablo Neira Ayuso
@ 2020-10-14 15:54 ` Arturo Borrero Gonzalez
  2020-10-14 18:47   ` Pablo Neira Ayuso
  0 siblings, 1 reply; 5+ messages in thread
From: Arturo Borrero Gonzalez @ 2020-10-14 15:54 UTC (permalink / raw)
  To: Pablo Neira Ayuso, netfilter-devel

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH nft] src: ingress inet support
  2020-10-14 15:54 ` Arturo Borrero Gonzalez
@ 2020-10-14 18:47   ` Pablo Neira Ayuso
  2020-10-14 18:48     ` Pablo Neira Ayuso
  0 siblings, 1 reply; 5+ messages in thread
From: Pablo Neira Ayuso @ 2020-10-14 18:47 UTC (permalink / raw)
  To: Arturo Borrero Gonzalez; +Cc: netfilter-devel

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH nft] src: ingress inet support
  2020-10-14 18:47   ` Pablo Neira Ayuso
@ 2020-10-14 18:48     ` Pablo Neira Ayuso
  2020-10-15  9:16       ` Arturo Borrero Gonzalez
  0 siblings, 1 reply; 5+ messages in thread
From: Pablo Neira Ayuso @ 2020-10-14 18:48 UTC (permalink / raw)
  To: Arturo Borrero Gonzalez; +Cc: netfilter-devel


[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]

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.

[-- Attachment #2: x.patch --]
[-- Type: text/x-diff, Size: 2728 bytes --]

diff --git a/doc/nft.txt b/doc/nft.txt
index 5326de167de8..02aefb1589e6 100644
--- a/doc/nft.txt
+++ b/doc/nft.txt
@@ -217,6 +217,10 @@ Packets forwarded to a different host are processed by the forward hook.
 Packets sent by local processes are processed by the output hook.
 |postrouting |
 All packets leaving the system are processed by the postrouting hook.
+|ingress |
+All packets entering the system are processed by this hook. It is invoked before
+layer 3 protocol handlers, hence before the prerouting hook, and it can be used
+for filtering and policing. Ingress is only available for Inet.
 |===================
 
 ARP ADDRESS FAMILY
@@ -242,15 +246,18 @@ The list of supported hooks is identical to IPv4/IPv6/Inet address families abov
 
 NETDEV ADDRESS FAMILY
 ~~~~~~~~~~~~~~~~~~~~
-The Netdev address family handles packets from ingress.
+The Netdev address family handles packets from the device ingress path. This
+family allows you to filter packets of any ethertype such as ARP, VLAN 802.1q,
+VLAN 802.1ad (Q-in-Q) as well as IPv4 and IPv6 packets.
 
 .Netdev address family hooks
 [options="header"]
 |=================
 |Hook | Description
 |ingress |
-All packets entering the system are processed by this hook. It is invoked before
-layer 3 protocol handlers and it can be used for early filtering and policing.
+All packets entering the system are processed by this hook. It is invoked after
+the network taps (ie. *tcpdump*), right after *tc* ingress and before layer 3
+protocol handlers, it can be used for early filtering and policing.
 |=================
 
 RULESET
@@ -373,7 +380,7 @@ This allows to e.g. implement policy routing selectors in nftables.
 |=================
 
 Apart from the special cases illustrated above (e.g. *nat* type not supporting
-*forward* hook or *route* type only supporting *output* hook), there are two
+*forward* hook or *route* type only supporting *output* hook), there are three
 further quirks worth noticing:
 
 * The netdev family supports merely a single combination, namely *filter* type and
@@ -381,6 +388,10 @@ further quirks worth noticing:
   to be present since they exist per incoming interface only.
 * The arp family supports only the *input* and *output* hooks, both in chains of type
   *filter*.
+* The inet family also supports the *ingress* hook, to filter IPv4 and IPv6
+  packet at the same location as the netdev *ingress* hook. This inet hook
+  allows you to share sets and maps between the usual *prerouting*,
+  *input*, *forward*, *output*, *postrouting* and this *ingress* hook.
 
 The *priority* parameter accepts a signed integer value or a standard priority
 name which specifies the order in which chains with same *hook* value are

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH nft] src: ingress inet support
  2020-10-14 18:48     ` Pablo Neira Ayuso
@ 2020-10-15  9:16       ` Arturo Borrero Gonzalez
  0 siblings, 0 replies; 5+ messages in thread
From: Arturo Borrero Gonzalez @ 2020-10-15  9:16 UTC (permalink / raw)
  To: Pablo Neira Ayuso; +Cc: netfilter-devel

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!

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-13 11:38 [PATCH nft] src: ingress inet support Pablo Neira Ayuso
2020-10-14 15:54 ` Arturo Borrero Gonzalez
2020-10-14 18:47   ` Pablo Neira Ayuso
2020-10-14 18:48     ` Pablo Neira Ayuso
2020-10-15  9:16       ` Arturo Borrero Gonzalez

Netfilter-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/netfilter-devel/0 netfilter-devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 netfilter-devel netfilter-devel/ https://lore.kernel.org/netfilter-devel \
		netfilter-devel@vger.kernel.org
	public-inbox-index netfilter-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.netfilter-devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git