* Re: nftables 0.9.3, sets with concatentation
2020-03-20 15:51 nftables 0.9.3, sets with concatentation Stefan Hartmann
@ 2020-03-20 16:37 ` Florian Westphal
2020-03-20 16:41 ` Frank Myhr
2020-03-21 10:17 ` Stefan Hartmann
2 siblings, 0 replies; 6+ messages in thread
From: Florian Westphal @ 2020-03-20 16:37 UTC (permalink / raw)
To: Stefan Hartmann; +Cc: netfilter.org
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).
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: nftables 0.9.3, sets with concatentation
2020-03-20 15:51 nftables 0.9.3, sets with concatentation Stefan Hartmann
2020-03-20 16:37 ` Florian Westphal
@ 2020-03-20 16:41 ` Frank Myhr
2020-03-20 16:46 ` Frank Myhr
2020-03-21 10:17 ` Stefan Hartmann
2 siblings, 1 reply; 6+ messages in thread
From: Frank Myhr @ 2020-03-20 16:41 UTC (permalink / raw)
To: Stefan Hartmann, netfilter.org
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: nftables 0.9.3, sets with concatentation
2020-03-20 16:41 ` Frank Myhr
@ 2020-03-20 16:46 ` Frank Myhr
0 siblings, 0 replies; 6+ messages in thread
From: Frank Myhr @ 2020-03-20 16:46 UTC (permalink / raw)
To: Stefan Hartmann, netfilter.org
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: nftables 0.9.3, sets with concatentation
2020-03-20 15:51 nftables 0.9.3, sets with concatentation Stefan Hartmann
2020-03-20 16:37 ` Florian Westphal
2020-03-20 16:41 ` Frank Myhr
@ 2020-03-21 10:17 ` Stefan Hartmann
2020-03-21 14:24 ` Frank Myhr
2 siblings, 1 reply; 6+ messages in thread
From: Stefan Hartmann @ 2020-03-21 10:17 UTC (permalink / raw)
To: netfilter.org
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: nftables 0.9.3, sets with concatentation
2020-03-21 10:17 ` Stefan Hartmann
@ 2020-03-21 14:24 ` Frank Myhr
0 siblings, 0 replies; 6+ messages in thread
From: Frank Myhr @ 2020-03-21 14:24 UTC (permalink / raw)
To: Stefan Hartmann, netfilter.org
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
^ permalink raw reply [flat|nested] 6+ messages in thread