From: Frank Myhr <fmyhr@fhmtech.com>
To: Stefan Hartmann <stefanh@hafenthal.de>, netfilter@vger.kernel.org
Subject: Re: nftables carefully open the related-flow: ct state related ct helper "ftp-21" ...
Date: Sun, 7 Mar 2021 15:06:46 -0500 [thread overview]
Message-ID: <052d6523-bf4b-fadf-b95d-15bd63457cef@fhmtech.com> (raw)
In-Reply-To: <ae754fef-dbae-6a71-b7d5-b730bc21c363@hafenthal.de>
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
next prev parent reply other threads:[~2021-03-07 20:06 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-07 15:12 nftables carefully open the related-flow: ct state related ct helper "ftp-21" Stefan Hartmann
2021-03-07 20:06 ` Frank Myhr [this message]
2021-03-08 9:24 ` Stefan Hartmann
2021-03-08 12:48 ` Frank Myhr
2021-03-08 19:22 ` Stefan Hartmann
2021-03-08 19:59 ` Frank Myhr
2021-03-08 21:05 ` Florian Westphal
2021-03-09 16:13 ` Stefan Hartmann
2021-03-09 16:59 ` Frank Myhr
2021-03-09 17:24 ` Florian Westphal
2021-03-09 17:29 ` Frank Myhr
2021-03-09 21:06 ` Pablo Neira Ayuso
2021-03-10 0:13 ` Frank Myhr
2021-03-15 11:18 ` Frank Myhr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=052d6523-bf4b-fadf-b95d-15bd63457cef@fhmtech.com \
--to=fmyhr@fhmtech.com \
--cc=netfilter@vger.kernel.org \
--cc=stefanh@hafenthal.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox