nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Stefan Hartmann]

Hi,

I want to carefully open the related-flow and noticed that I cannot 
concatenate the two ct expressions:

		ct state related ct helper "HELPER" ... accept


Simple example with ftp-helper:
...
chain INPUT4 { vom VPN-Peer,
         type filter hook input priority 0; policy drop;


	ct state established counter accept
	
	# would be nice to match on state related AND applied helper
	ct state related ct helper "ftp-21" tcp dport {1024-65535} counter accept
	
	ct state related ct helper "ftp-21" counter log prefix "NFT: 
FILTER4/INPUT4: p. died :" group 0 drop
	
	# I want not care about other related traffic
	ct state related counter accept

	...


Simple Workaround, which could be unsecure in certain circumstances, eg 
using different helpers, sip-A, sip-B, sip-C:
	
	ct state established counter accept
	ct state related tcp dport {1024-65535} counter accept


Is the concatenation possible or have I to use another syntax, eg 
different chains?

Tested on nftables 0.9.8-3 on Debian Bullseye.


-- 
Thanks,
Stefan Hartmann

Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Frank Myhr]

On 2021/03/07 10:12, Stefan Hartmann wrote:
> Hi,
> 
> I want to carefully open the related-flow and noticed that I cannot 
> concatenate the two ct expressions:
> 
>          ct state related ct helper "HELPER" ... accept
> 
> 
> Simple example with ftp-helper:
> ...
> chain INPUT4 { vom VPN-Peer,
>          type filter hook input priority 0; policy drop;
> 
> 
>      ct state established counter accept
> 
>      # would be nice to match on state related AND applied helper
>      ct state related ct helper "ftp-21" tcp dport {1024-65535} counter 
> accept

Hi Stefan,

I guess the problem is that input tcp packets with dport {1024-65535} 
that are matched by "ftp-21" ct helper are by definition related packets 
(to the original connection to tcp/21), so the explicit "ct state 
related" match in your INPUT4 chain rule is redundant. You didn't show 
your "ftp-21" ct helper (stateful object) definition, I suppose it is 
something like those at:

https://wiki.nftables.org/wiki-nftables/index.php/Setting_packet_connection_tracking_metainformation

Then you'd have something like (warning, untested):

table my_table {

   ct helper ftp-21 {
     type "ftp" protocol tcp;
   }

   chain ct_helper_assign {
     type filter hook prerouting priority filter;

       ct state new tcp dport 21 ct helper set "ftp-21"
   }

   chain INPUT4 {
     type filter hook input priority filter; policy drop;
     ...
     ct helper "ftp-21" tcp dport {1024-65535} counter accept
     ...
   }
   ...
}

In the above ruleset "ftp-21 related" packets are accepted in a 2-step 
process:

1) In the prerouting hook such packets receive "ftp-21 related" status 
when the "ftp-21" "ftp" helper recognizes them as matching expectations 
it created based on recent packets to tcp/21;

2) In the input hook such packets are matched (with additional tcp dport 
restriction), counted, and accepted by the rule in your INPUT4 chain.

This explicit 2-step process differs from the way ct helpers worked 
using iptables, for example:
https://home.regit.org/netfilter-en/secure-use-of-helpers/


Best Wishes,
Frank

Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Stefan Hartmann]

On 07.03.21 21:06, Frank Myhr wrote:
> On 2021/03/07 10:12, Stefan Hartmann wrote:
>> Hi,
>>
>> I want to carefully open the related-flow and noticed that I cannot 
>> concatenate the two ct expressions:
>>
>>          ct state related ct helper "HELPER" ... accept
>>
>>
>> Simple example with ftp-helper:
>> ...
>> chain INPUT4 { vom VPN-Peer,
>>          type filter hook input priority 0; policy drop;
>>
>>
>>      ct state established counter accept
>>
>>      # would be nice to match on state related AND applied helper
>>      ct state related ct helper "ftp-21" tcp dport {1024-65535} 
>> counter accept
> 
> Hi Stefan,
> 
> I guess the problem is that input tcp packets with dport {1024-65535} 
> that are matched by "ftp-21" ct helper are by definition related packets 
> (to the original connection to tcp/21), so the explicit "ct state 
> related" match in your INPUT4 chain rule is redundant. You didn't show 
> your "ftp-21" ct helper (stateful object) definition, I suppose it is 
> something like those at:
> 
> https://wiki.nftables.org/wiki-nftables/index.php/Setting_packet_connection_tracking_metainformation 

Thank you Frank for your prompt reply!

Sorry, I should have mention it. I tried the snooping of the master 
connection with different approaches, which all worked as espected, eg

chain PREROUTING-FILTER4 {  # After CT, Prio 0, filter
         type filter hook prerouting priority 0; policy accept;
	tcp dport 21 counter ct helper set "ftp-21"

or

chain INPUT4 { vom VPN-Peer,
         type filter hook input priority 0; policy drop;
	
	...
	tcp dport 21 ip daddr $IF1_IP4 counter ct helper set "ftp-21" accept		# 
initial traffic AND snooping


> 
> Then you'd have something like (warning, untested):
> 
> table my_table {
> 
>    ct helper ftp-21 {
>      type "ftp" protocol tcp;
>    }
> 
>    chain ct_helper_assign {
>      type filter hook prerouting priority filter;
> 
>        ct state new tcp dport 21 ct helper set "ftp-21"
>    }
> 
>    chain INPUT4 {
>      type filter hook input priority filter; policy drop;
>      ...
>      ct helper "ftp-21" tcp dport {1024-65535} counter accept
>      ...
>    }
>    ...
> }
> 
> In the above ruleset "ftp-21 related" packets are accepted in a 2-step 
> process:
> 
> 1) In the prerouting hook such packets receive "ftp-21 related" status 
> when the "ftp-21" "ftp" helper recognizes them as matching expectations 
> it created based on recent packets to tcp/21;
> 
> 2) In the input hook such packets are matched (with additional tcp dport 
> restriction), counted, and accepted by the rule in your INPUT4 chain.
> 
> This explicit 2-step process differs from the way ct helpers worked 
> using iptables, for example:
> https://home.regit.org/netfilter-en/secure-use-of-helpers/
> 
> 
> Best Wishes,
> Frank


In chain INPUT4 {

	your mentioned rule
	ct helper "ftp-21" tcp dport {1024-65535} counter accept

did not match in my test.

Eventually the ct helper "ftp-21" matches only on the master connection 
and not for the expects?
I should have to dig into the source code, but because of time 
constraints this is not yet possible.

I will go now with this simple approach, which is only an example:
	ct state established counter accept 

         ct state related tcp dport {1024-65535} ip saddr $SITE-S18_NET4 
counter accept

The goal is to carefully open the related flows to different SIP ITSPs.

-- 
Cheers, Stefan Hartmann

Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Frank Myhr]

On 2021/03/08 04:24, Stefan Hartmann wrote:

> In chain INPUT4 {
> 
>      your mentioned rule
>      ct helper "ftp-21" tcp dport {1024-65535} counter accept
> 
> did not match in my test.
> 
> Eventually the ct helper "ftp-21" matches only on the master connection 
> and not for the expects?

What if you do (untested):

table my_table {

   ct helper ftp-21 {
     type "ftp" protocol tcp;
   }

   chain ct_helper_assign {
     type filter hook prerouting priority filter;

       ct state new tcp dport 21 ct helper set "ftp-21"
   }

   chain INPUT4 {
     type filter hook input priority filter; policy drop;
     ...
     tcp dport 21 counter accept   # accept ftp control packets
     ct helper "ftp-21" tcp dport {1024-65535} counter accept
     ...
     limit rate 15/hour burst 30 packets     log prefix "drop: "
   }
   ...
}

Differences from previous ruleset:
1) Add accept rule to tcp/21 for ftp control packets
2) Add log rule (at least during debug) to see dropped packets.

Best Wishes,
Frank

Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Stefan Hartmann]

I tested with this sequence, with multiple counters and no verdicts and 
nflog:

chain INPUT4 {
	type filter hook input priority 0; policy drop;
	iifname "lo" accept
	ct state established counter packets 403 bytes 26976 accept
	ct state related counter packets 1 bytes 60
	ct helper "ftp-21" counter packets 0 bytes 0
	ct state related ct helper "ftp-21" counter packets 0 bytes 0 accept
	ct state related counter packets 1 bytes 60 log group 10
	ct state related counter packets 1 bytes 60 accept
	ip protocol icmp accept
	tcp dport ssh accept
	tcp dport ftp ip daddr 10.18.16.143 counter packets 1 bytes 60 ct 
helper set "ftp-21" accept
	counter packets 0 bytes 0 log prefix "NFT: FILTER4/INPUT4: p. died: " 
group 0 drop
	}

And indeed, the RELATED packet going through is the SYN packet from the 
FTP DATA flow.

The ct helper "ftp-21" matches NOT on the RELATED packets, it matches 
pretty sure on the master connection.
I will try to verificate this.


-- 
Cheers Stefan Hartmann

Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Frank Myhr]

On 2021/03/08 14:22, Stefan Hartmann wrote:
> I tested with this sequence, with multiple counters and no verdicts and 
> nflog:
> 
> chain INPUT4 {
>      type filter hook input priority 0; policy drop;
>      iifname "lo" accept
>      ct state established counter packets 403 bytes 26976 accept
>      ct state related counter packets 1 bytes 60
>      ct helper "ftp-21" counter packets 0 bytes 0
>      ct state related ct helper "ftp-21" counter packets 0 bytes 0 accept
>      ct state related counter packets 1 bytes 60 log group 10
>      ct state related counter packets 1 bytes 60 accept
>      ip protocol icmp accept
>      tcp dport ssh accept
>      tcp dport ftp ip daddr 10.18.16.143 counter packets 1 bytes 60 ct 
> helper set "ftp-21" accept
>      counter packets 0 bytes 0 log prefix "NFT: FILTER4/INPUT4: p. died: 
> " group 0 drop
>      }
> 
> And indeed, the RELATED packet going through is the SYN packet from the 
> FTP DATA flow.
> 
> The ct helper "ftp-21" matches NOT on the RELATED packets, it matches 
> pretty sure on the master connection.
> I will try to verificate this.


Thanks for including the output with counters. I'd advise removing the
'ct helper set "ftp-21"' from the last 'accept' rule in your INPUT4 
input chain to get simply:

tcp dport ftp ip daddr 10.18.16.143 accept

And adding the ct helper 'ftp-21' definition and a _prerouting_ chain 
with your helper rule as in the earlier example I sent, and:

https://wiki.nftables.org/wiki-nftables/index.php/Setting_packet_connection_tracking_metainformation

https://www.mankier.com/8/nft#Stateful_Objects-CT_Helper

I think having the helper rule in _prerouting_ rather than _input_ may 
change what you see...

Best Wishes,
Frank

Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Florian Westphal]

Stefan Hartmann <stefanh@hafenthal.de> wrote:
> I tested with this sequence, with multiple counters and no verdicts and
> nflog:
> 
> chain INPUT4 {
> 	type filter hook input priority 0; policy drop;
> 	iifname "lo" accept
> 	ct state established counter packets 403 bytes 26976 accept
> 	ct state related counter packets 1 bytes 60
> 	ct helper "ftp-21" counter packets 0 bytes 0
> 	ct state related ct helper "ftp-21" counter packets 0 bytes 0 accept
> 	ct state related counter packets 1 bytes 60 log group 10
> 	ct state related counter packets 1 bytes 60 accept
> 	ip protocol icmp accept
> 	tcp dport ssh accept
> 	tcp dport ftp ip daddr 10.18.16.143 counter packets 1 bytes 60 ct helper
> set "ftp-21" accept
> 	counter packets 0 bytes 0 log prefix "NFT: FILTER4/INPUT4: p. died: " group
> 0 drop
> 	}
> 
> And indeed, the RELATED packet going through is the SYN packet from the FTP
> DATA flow.
> 
> The ct helper "ftp-21" matches NOT on the RELATED packets, it matches pretty
> sure on the master connection.
> I will try to verificate this.

'ct state related ct helper "ftp"' should work for data connections.

Problem is that 'ct helper' fetches the in-kernel name of the helper
("ftp" in this case) and not the object name defined in the ruleset or
used for assignment.

Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Stefan Hartmann]

On 08.03.21 22:05, Florian Westphal wrote:
> 'ct helper' fetches the in-kernel name of the helper
> ("ftp" in this case) and not the object name defined in the ruleset or
> used for assignment

Thank you, this is the necessary hint!

The ct helper "ftp" matches on the RELATED packets.

It matches not on the master connection, my previous sugestion was wrong.


For the sake of completeness, here my nftables ftp-helper test ruleset:

Active ruleset: ================.
table ip FILTER4 {
	ct helper ftp-21 {
		type "ftp" protocol tcp
		l3proto ip
	}

	chain PREROUTING-EARLY4 {
		type filter hook prerouting priority -300; policy accept;
	}

	chain PREROUTING-MANGLE4 {
		type filter hook prerouting priority -150; policy accept;
	}

	chain PREROUTING-NAT4 {
		type nat hook prerouting priority -100; policy accept;
	}

	chain PREROUTING-FILTER4 {
		type filter hook prerouting priority 0; policy accept;
	}

	chain FORWARD4 {
		type filter hook forward priority 0; policy drop;
		counter packets 0 bytes 0 log prefix "NFT: FILTER4/FORWARD4: p. died: 
" group 0 drop
	}

	chain INPUT4 {
		type filter hook input priority 0; policy drop;
		iifname "lo" accept
		ct state established counter packets 317 bytes 20876 accept
		ct state related ct helper "ftp" tcp dport { 1024-65535 } ip saddr 
10.18.0.0/19 counter packets 3 bytes 180 accept
		ct state related ct helper "ftp" counter packets 0 bytes 0 log prefix 
"NFT: FILTER4/INPUT4: p. died :" group 0 drop
		ct state related counter packets 0 bytes 0 accept
		ip protocol icmp accept
		tcp dport ssh accept
		tcp dport ftp ip daddr 10.18.16.143 counter packets 2 bytes 120 ct 
helper set "ftp-21" accept
		counter packets 0 bytes 0 log prefix "NFT: FILTER4/INPUT4: p. died: " 
group 0 drop
	}

	chain OUTPUT-MANGLE4 {
		type route hook output priority -150; policy accept;
	}

	chain OUTPUT4 {
		type filter hook output priority 0; policy drop;
		oifname "lo" accept
		ct state established counter packets 250 bytes 1073349 accept
		ct state related ct helper "ftp" tcp sport ftp-data ip daddr 
10.18.0.0/19 counter packets 3 bytes 180 accept
		ct state related ct helper "ftp" counter packets 0 bytes 0 log prefix 
"NFT: FILTER4/OUTPUT4: p. died :" group 0 drop
		ct state related counter packets 0 bytes 0 accept
		ip protocol icmp accept
		udp dport { domain, ntp } ip daddr 10.18.0.0/19 accept
		tcp dport { domain, 3128 } ip daddr 10.18.0.0/19 accept
		counter packets 0 bytes 0 log prefix "NFT: FILTER4/OUTPUT4: p. died :" 
group 0 drop
	}

	chain POSTROUTING-MANGLE4 {
		type filter hook postrouting priority -150; policy accept;
	}

	chain POSTROUTING-NAT4 {
		type nat hook postrouting priority 100; policy accept;
	}
}
[info] End of ruleset: ================.


-- 
Cheers Stefan Hartmann

Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Frank Myhr]

On 2021/03/09 11:13, Stefan Hartmann wrote:
> On 08.03.21 22:05, Florian Westphal wrote:
>> 'ct helper' fetches the in-kernel name of the helper
>> ("ftp" in this case) and not the object name defined in the ruleset or
>> used for assignment
> 
> Thank you, this is the necessary hint!
> 
> The ct helper "ftp" matches on the RELATED packets.

Stefan, congrats on getting your configuration working. :-)
And thank you very much for posting your complete ruleset below.

Florian, I hope you can comment:

1) I will look at the code, but am surprised that "ct helper" uses the 
in-kernel name "ftp" rather than that of the stateful object "ftp-21" 
that the ruleset goes to the trouble of explicitly defining.

a) Is this simply a parsing artifact -- if the helper were called "abcd" 
would the expression 'ct helper "abcd"' match it?

b) If it is NOT a parsing artifact but by design: why? It would be more 
intuitive to use the name of the explicitly-named helper object. Another 
way to ask the same thing: why bother with the explicit helper object at 
all, rather than just use "ftp" (which implies the ip & tcp protocols in 
"ftp-21" definition anyway) in both match and statement, like 'ct helper 
set "ftp"'?


2) Does it make a difference whether 'ct helper set' is done in input 
(as in below ruleset) or in prerouting? Maybe it has to be in prerouting 
only in case of forwarded traffic?

https://wiki.nftables.org/wiki-nftables/index.php/Conntrack_helpers
currently says:
"You have to attach your conntrack helper from the prerouting chain."

Thanks,
Frank


> For the sake of completeness, here my nftables ftp-helper test ruleset:
> 
> Active ruleset: ================.
> table ip FILTER4 {
>      ct helper ftp-21 {
>          type "ftp" protocol tcp
>          l3proto ip
>      }
> 
>      chain PREROUTING-EARLY4 {
>          type filter hook prerouting priority -300; policy accept;
>      }
> 
>      chain PREROUTING-MANGLE4 {
>          type filter hook prerouting priority -150; policy accept;
>      }
> 
>      chain PREROUTING-NAT4 {
>          type nat hook prerouting priority -100; policy accept;
>      }
> 
>      chain PREROUTING-FILTER4 {
>          type filter hook prerouting priority 0; policy accept;
>      }
> 
>      chain FORWARD4 {
>          type filter hook forward priority 0; policy drop;
>          counter packets 0 bytes 0 log prefix "NFT: FILTER4/FORWARD4: p. 
> died: " group 0 drop
>      }
> 
>      chain INPUT4 {
>          type filter hook input priority 0; policy drop;
>          iifname "lo" accept
>          ct state established counter packets 317 bytes 20876 accept
>          ct state related ct helper "ftp" tcp dport { 1024-65535 } ip 
> saddr 10.18.0.0/19 counter packets 3 bytes 180 accept
>          ct state related ct helper "ftp" counter packets 0 bytes 0 log 
> prefix "NFT: FILTER4/INPUT4: p. died :" group 0 drop
>          ct state related counter packets 0 bytes 0 accept
>          ip protocol icmp accept
>          tcp dport ssh accept
>          tcp dport ftp ip daddr 10.18.16.143 counter packets 2 bytes 120 
> ct helper set "ftp-21" accept
>          counter packets 0 bytes 0 log prefix "NFT: FILTER4/INPUT4: p. 
> died: " group 0 drop
>      }
> 
>      chain OUTPUT-MANGLE4 {
>          type route hook output priority -150; policy accept;
>      }
> 
>      chain OUTPUT4 {
>          type filter hook output priority 0; policy drop;
>          oifname "lo" accept
>          ct state established counter packets 250 bytes 1073349 accept
>          ct state related ct helper "ftp" tcp sport ftp-data ip daddr 
> 10.18.0.0/19 counter packets 3 bytes 180 accept
>          ct state related ct helper "ftp" counter packets 0 bytes 0 log 
> prefix "NFT: FILTER4/OUTPUT4: p. died :" group 0 drop
>          ct state related counter packets 0 bytes 0 accept
>          ip protocol icmp accept
>          udp dport { domain, ntp } ip daddr 10.18.0.0/19 accept
>          tcp dport { domain, 3128 } ip daddr 10.18.0.0/19 accept
>          counter packets 0 bytes 0 log prefix "NFT: FILTER4/OUTPUT4: p. 
> died :" group 0 drop
>      }
> 
>      chain POSTROUTING-MANGLE4 {
>          type filter hook postrouting priority -150; policy accept;
>      }
> 
>      chain POSTROUTING-NAT4 {
>          type nat hook postrouting priority 100; policy accept;
>      }
> }
> [info] End of ruleset: ================.
> 
> 

Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Florian Westphal]

Frank Myhr <fmyhr@fhmtech.com> wrote:
> > The ct helper "ftp" matches on the RELATED packets.
> 
> Stefan, congrats on getting your configuration working. :-)
> And thank you very much for posting your complete ruleset below.
> 
> Florian, I hope you can comment:
> 
> 1) I will look at the code, but am surprised that "ct helper" uses the
> in-kernel name "ftp" rather than that of the stateful object "ftp-21" that
> the ruleset goes to the trouble of explicitly defining.
> 
> a) Is this simply a parsing artifact -- if the helper were called "abcd"
> would the expression 'ct helper "abcd"' match it?
> 
> b) If it is NOT a parsing artifact but by design: why? It would be more
> intuitive to use the name of the explicitly-named helper object. Another way
> to ask the same thing: why bother with the explicit helper object at all,
> rather than just use "ftp" (which implies the ip & tcp protocols in "ftp-21"
> definition anyway) in both match and statement, like 'ct helper set "ftp"'?

Its a design fuckup.  When I made the objref patches to attach the
defined helpers I did not consider that we already had a 'ct helper'
with existing behaviour.

The explicit helper objects were done this way to allow defining
multiple helpers wuth different settings.

There are helpers that can be tuned by options and users might want to
use different settings in each.

> 2) Does it make a difference whether 'ct helper set' is done in input (as in
> below ruleset) or in prerouting? Maybe it has to be in prerouting only in
> case of forwarded traffic?

It can be in input if the traffic is not forwarded.

Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Frank Myhr]

On 2021/03/09 12:24, Florian Westphal wrote:
> Frank Myhr <fmyhr@fhmtech.com> wrote:
>> 1) I will look at the code, but am surprised that "ct helper" uses the
>> in-kernel name "ftp" rather than that of the stateful object "ftp-21" that
>> the ruleset goes to the trouble of explicitly defining.
>>
>> a) Is this simply a parsing artifact -- if the helper were called "abcd"
>> would the expression 'ct helper "abcd"' match it?
>>
>> b) If it is NOT a parsing artifact but by design: why? It would be more
>> intuitive to use the name of the explicitly-named helper object. Another way
>> to ask the same thing: why bother with the explicit helper object at all,
>> rather than just use "ftp" (which implies the ip & tcp protocols in "ftp-21"
>> definition anyway) in both match and statement, like 'ct helper set "ftp"'?
> 
> Its a design fuckup.  When I made the objref patches to attach the
> defined helpers I did not consider that we already had a 'ct helper'
> with existing behaviour.
> 
> The explicit helper objects were done this way to allow defining
> multiple helpers wuth different settings.
> 
> There are helpers that can be tuned by options and users might want to
> use different settings in each.

Got it. Thank you for very much for explaining the history and rationale.


>> 2) Does it make a difference whether 'ct helper set' is done in input (as in
>> below ruleset) or in prerouting? Maybe it has to be in prerouting only in
>> case of forwarded traffic?
> 
> It can be in input if the traffic is not forwarded.

Thanks for confirming. I'll make the wiki page more explicit on this point.

Best Wishes,
Frank

Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Pablo Neira Ayuso]

On Tue, Mar 09, 2021 at 06:24:28PM +0100, Florian Westphal wrote:
> Frank Myhr <fmyhr@fhmtech.com> wrote:
> > > The ct helper "ftp" matches on the RELATED packets.
> > 
> > Stefan, congrats on getting your configuration working. :-)
> > And thank you very much for posting your complete ruleset below.
> > 
> > Florian, I hope you can comment:
> > 
> > 1) I will look at the code, but am surprised that "ct helper" uses the
> > in-kernel name "ftp" rather than that of the stateful object "ftp-21" that
> > the ruleset goes to the trouble of explicitly defining.
> > 
> > a) Is this simply a parsing artifact -- if the helper were called "abcd"
> > would the expression 'ct helper "abcd"' match it?
> > 
> > b) If it is NOT a parsing artifact but by design: why? It would be more
> > intuitive to use the name of the explicitly-named helper object. Another way
> > to ask the same thing: why bother with the explicit helper object at all,
> > rather than just use "ftp" (which implies the ip & tcp protocols in "ftp-21"
> > definition anyway) in both match and statement, like 'ct helper set "ftp"'?
> 
> Its a design fuckup.  When I made the objref patches to attach the
> defined helpers I did not consider that we already had a 'ct helper'
> with existing behaviour.
> 
> The explicit helper objects were done this way to allow defining
> multiple helpers wuth different settings.
> 
> There are helpers that can be tuned by options and users might want to
> use different settings in each.

Just posted a patchset, maybe we can address this inconsistency moving
forward:

https://patchwork.ozlabs.org/project/netfilter-devel/patch/20210309210134.13620-2-pablo@netfilter.org/
https://patchwork.ozlabs.org/project/netfilter-devel/patch/20210309210134.13620-3-pablo@netfilter.org/

> > 2) Does it make a difference whether 'ct helper set' is done in input (as in
> > below ruleset) or in prerouting? Maybe it has to be in prerouting only in
> > case of forwarded traffic?
> 
> It can be in input if the traffic is not forwarded.

Actually it can be place in forward chain too IIRC.

If the rule is added to prerouting, then the ct helper is attached to
both input and forward traffic.

Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Frank Myhr]

On 2021/03/09 16:06, Pablo Neira Ayuso wrote:
> On Tue, Mar 09, 2021 at 06:24:28PM +0100, Florian Westphal wrote:
>> Frank Myhr <fmyhr@fhmtech.com> wrote:
>>> 1) I will look at the code, but am surprised that "ct helper" uses the
>>> in-kernel name "ftp" rather than that of the stateful object "ftp-21" that
>>> the ruleset goes to the trouble of explicitly defining.
>>>
>>> a) Is this simply a parsing artifact -- if the helper were called "abcd"
>>> would the expression 'ct helper "abcd"' match it?
>>>
>>> b) If it is NOT a parsing artifact but by design: why? It would be more
>>> intuitive to use the name of the explicitly-named helper object. Another way
>>> to ask the same thing: why bother with the explicit helper object at all,
>>> rather than just use "ftp" (which implies the ip & tcp protocols in "ftp-21"
>>> definition anyway) in both match and statement, like 'ct helper set "ftp"'?
>>
>> Its a design fuckup.  When I made the objref patches to attach the
>> defined helpers I did not consider that we already had a 'ct helper'
>> with existing behaviour.
>>
>> The explicit helper objects were done this way to allow defining
>> multiple helpers wuth different settings.
>>
>> There are helpers that can be tuned by options and users might want to
>> use different settings in each.
> 
> Just posted a patchset, maybe we can address this inconsistency moving
> forward:
> 
> https://patchwork.ozlabs.org/project/netfilter-devel/patch/20210309210134.13620-2-pablo@netfilter.org/
> https://patchwork.ozlabs.org/project/netfilter-devel/patch/20210309210134.13620-3-pablo@netfilter.org/

Cool! Thanks!!!


>>> 2) Does it make a difference whether 'ct helper set' is done in input (as in
>>> below ruleset) or in prerouting? Maybe it has to be in prerouting only in
>>> case of forwarded traffic?
>>
>> It can be in input if the traffic is not forwarded.
> 
> Actually it can be place in forward chain too IIRC.
> 
> If the rule is added to prerouting, then the ct helper is attached to
> both input and forward traffic.

Thanks - I will add to the wiki page.

Best Wishes,
Frank

Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...

[Frank Myhr]

> On Tue, Mar 09, 2021 at 06:24:28PM +0100, Florian Westphal wrote:
>> The explicit helper objects were done this way to allow defining
>> multiple helpers wuth different settings.
>>
>> There are helpers that can be tuned by options and users might want to
>> use different settings in each.

So a helper definition

ct helper sip-udp {
     type "sip" protocol udp;
}

can configure options sip_timeout, sip_direct_signalling, 
sip_direct_media, sip_external_media? How?

Thanks,
Frank