nftables 0.9.3, sets with concatentation

nftables 0.9.3, sets with concatentation

[Stefan Hartmann]

I have successfully migrated from a cisco IOS router to a new GNU/Linux 
Debian box with nftables 0.9.3.

At now I am trying to simplify the configuration with sets.
E.g.
table ip FILTER4 {
	set s4_ICMP-RELATED {
		type icmp_type
		elements = { destination-unreachable,
			     time-exceeded }

and using this set
...
chain ACL4-IN_IF2 {
		ct state invalid log prefix "NFT: FILTER4/ACL4-IN_IF2: ct invalid: " drop
		ct state established,related accept
		icmp type @s4_ICMP-RELATED accept
		...

This works perfectly with sets without concatenation.


For the sake of a well-arranged ruleset,
it would be nice to have a concatenated set like
	set s4_MISC-SERVICES {
		type inet_proto . inet_service
		elements = { udp . 69, tcp . 23 ]

and then use this set like
	ip daddr $IP4_IF2 . dport @s4_MISC-SERVICES accept

But I got a syntax error "unexpected dport".

With eg ip daddr $IP4_IF2 . udp dport @s4_MISC-SERVICES accept it is 
working, but this is here useless for simplyfying.

What is the right syntax or is the mixing of udp and tcp in this manner 
impossible?
Is there a better approach to get the abstraction from a group of 
services into a mixed tcp udp ruleset?


Thanks,
Stefan Hartmann

Re: nftables 0.9.3, sets with concatentation

[Florian Westphal]

Stefan Hartmann <stefanh@hafenthal.de> wrote:
> I have successfully migrated from a cisco IOS router to a new GNU/Linux
> Debian box with nftables 0.9.3.
> 
> At now I am trying to simplify the configuration with sets.
> E.g.
> table ip FILTER4 {
> 	set s4_ICMP-RELATED {
> 		type icmp_type
> 		elements = { destination-unreachable,
> 			     time-exceeded }
> 
> and using this set
> ...
> chain ACL4-IN_IF2 {
> 		ct state invalid log prefix "NFT: FILTER4/ACL4-IN_IF2: ct invalid: " drop
> 		ct state established,related accept
> 		icmp type @s4_ICMP-RELATED accept
> 		...
> 
> This works perfectly with sets without concatenation.
> 
> 
> For the sake of a well-arranged ruleset,
> it would be nice to have a concatenated set like
> 	set s4_MISC-SERVICES {
> 		type inet_proto . inet_service
> 		elements = { udp . 69, tcp . 23 ]
> 
> and then use this set like
> 	ip daddr $IP4_IF2 . dport @s4_MISC-SERVICES accept

try
 ... IF2 . th dport ..

(th == transport header).

Re: nftables 0.9.3, sets with concatentation

[Frank Myhr]

On 2020/03/20 11:51, Stefan Hartmann wrote:

> For the sake of a well-arranged ruleset,
> it would be nice to have a concatenated set like
>      set s4_MISC-SERVICES {
>          type inet_proto . inet_service
>          elements = { udp . 69, tcp . 23 ]
> 
> and then use this set like
>      ip daddr $IP4_IF2 . dport @s4_MISC-SERVICES accept
> 
> But I got a syntax error "unexpected dport".
> 
> With eg ip daddr $IP4_IF2 . udp dport @s4_MISC-SERVICES accept it is 
> working, but this is here useless for simplyfying.
> 
> What is the right syntax or is the mixing of udp and tcp in this manner 
> impossible?
> Is there a better approach to get the abstraction from a group of 
> services into a mixed tcp udp ruleset?

Hi Stefan,

Interesting problem. A simple approach would be to use 2 rules, one for 
udp services and one for tcp services.

But I get that you'd prefer to handle both in a single rule.
The man page suggests a solution: use the raw payload expression:
https://www.mankier.com/8/nft#Payload_Expressions-Raw_Payload_Expression

I'm unsure of exactly the match you're after, because in your example
set s4_MISC-SERVICES type is inet_proto . inet_service
but then you try to match against ipv4_addr . inet_service

If you in fact want ipv4_addr . inet_proto . inet_service
it looks like this should work:

set s4_MISC-SERVICES {
           type ipv4_addr . inet_proto . inet_service
           elements = { $IP4_IF2 . udp . 69, $IP4_IF2 . tcp . 23 ]

meta l4proto {tcp, udp} \
	ip daddr . meta l4proto . th dport @s4_MISC-SERVICES   accept


Or, you may well want to handle ipv4 addresses in a separate set:

set s4_MISC-SERV2 {
	type inet_proto . inet_service
       	elements = { udp . 69, tcp . 23 ]

set ip_allowed {
	type ipv4_addr
	elements = { $IP4_IF2 }

ip daddr @ ip_allowed   meta l4proto {tcp, udp} \
	meta l4proto . th dport @s4_MISC-SERVICES   accept


The apparently redundant meta l4proto {tcp, udp} in both versions above 
is because the man page notes you must take care not to use raw match 
without verifying the actual type of packet.


Disclaimer: I am an nftables newbie, and have not tried the above. But 
enjoyed taking a stab at it. Let us know if it works. :-)

Best regards,
Frank

Re: nftables 0.9.3, sets with concatentation

[Frank Myhr]

On 2020/03/20 12:41, Frank Myhr wrote:

> set s4_MISC-SERVICES {
>            type ipv4_addr . inet_proto . inet_service
>            elements = { $IP4_IF2 . udp . 69, $IP4_IF2 . tcp . 23 ]

Argh! Use a curly brace at the end rather than square bracket, 
obviously. ;-p


> meta l4proto {tcp, udp} \
>      ip daddr . meta l4proto . th dport @s4_MISC-SERVICES   accept
> 
> 
> Or, you may well want to handle ipv4 addresses in a separate set:
> 
> set s4_MISC-SERV2 {
>      type inet_proto . inet_service
>            elements = { udp . 69, tcp . 23 ]

Same here.


> set ip_allowed {
>      type ipv4_addr
>      elements = { $IP4_IF2 }

Add missing end brace }.


Sorry for the typos!

-F

Re: nftables 0.9.3, sets with concatentation

[Stefan Hartmann]

Thank you Florian and Frank for your suggestions. Yes, I found it now 
also in the man page under "RAW PAYLOAD EXPRESSION".

I tested step for step:

ip daddr $IP4_IF2 meta l4proto {udp, tcp} @th,16,16 {69, 23} accept		

ip daddr $IP4_IF2 meta l4proto . @th,16,16 {udp . 69, tcp . 23} accept

ip daddr $IP4_IF2 meta l4proto . @th,16,16 @CONCATENATED_SET_3 accept

and verified with netcat - it is functional in this way.


Could there be issues with conntrack, nat, etc with this approach?
I will test it in the next days.

Firstly I will start with separate UDP and TCP service groups.


Nb. I use separate ipv4 and ipv6 tables, because they are really 
different protocols. In my experience the mixing leads often to 
overlooked security flaws - I am working as pentester occasionally.

Re: nftables 0.9.3, sets with concatentation

[Frank Myhr]

On 2020/03/21 06:17, Stefan Hartmann wrote:
> Thank you Florian and Frank for your suggestions. Yes, I found it now 
> also in the man page under "RAW PAYLOAD EXPRESSION".
> 
> I tested step for step:
> 
> ip daddr $IP4_IF2 meta l4proto {udp, tcp} @th,16,16 {69, 23} accept
> 
> ip daddr $IP4_IF2 meta l4proto . @th,16,16 {udp . 69, tcp . 23} accept
> 
> ip daddr $IP4_IF2 meta l4proto . @th,16,16 @CONCATENATED_SET_3 accept
> 
> and verified with netcat - it is functional in this way.

Thanks for confirming that the above work.

And incidentally thank you for prompting me to look up character length 
limits on set names and other nftables objects. After cutting my 
firewall teeth using ipchains I'm leery of longish identifiers. AFAICT 
limits were/are:

ipchains: 8 characters (!)
https://www.tldp.org/HOWTO/IPCHAINS-HOWTO-4.html

iptables: 29 characters
https://github.com/torvalds/linux/blob/master/include/uapi/linux/netfilter/x_tables.h
   #define XT_EXTENSION_MAXNAMELEN 29

nftables: 256 characters
https://github.com/torvalds/linux/blob/master/include/uapi/linux/netfilter/nf_tables.h
   #define NFT_NAME_MAXLEN       256
   #define NFT_TABLE_MAXNAMELEN  NFT_NAME_MAXLEN
   #define NFT_CHAIN_MAXNAMELEN  NFT_NAME_MAXLEN
   #define NFT_SET_MAXNAMELEN    NFT_NAME_MAXLEN
   #define NFT_OBJ_MAXNAMELEN    NFT_NAME_MAXLEN


> Could there be issues with conntrack, nat, etc with this approach?
> I will test it in the next days.

I wouldn't expect so, but please report back.


> Firstly I will start with separate UDP and TCP service groups.

Sounds reasonable to me.


> Nb. I use separate ipv4 and ipv6 tables, because they are really 
> different protocols. In my experience the mixing leads often to 
> overlooked security flaws - I am working as pentester occasionally.

Thanks for your observation.

Cheers,
Frank