Re: ct state vmap (nft noob question)

Re: ct state vmap (nft noob question)

[Neal P. Murphy]

On Tue, 23 Jul 2019 19:12:23 +1000
"Trent W. Buck" <trentbuck@gmail.com> wrote:

> (I hope these questions aren't too stupid for this list!)
> 
> A stateful firewall ruleset usually starts like:
> 
>     ct state established,related accept
>     ct state invalid drop
>     # Hooray, 99% of packets are now decided;
>     # we only need to think hard the ones in ct state new!

Personally, I drop INVALID packets in PREROUTING in order to waste no more CPU cycles than are necessary because we already know that that packet cannot be processed.


> 
> If you want to guard against a coworker "accidentally" adding NOTRACK in
> raw, you might tweak that to drop "ct untracked" as well:
> 
>     ct state established,related accept
>     ct state != new drop
> 
> But nftables has these "verdict map" things now:
> 
>     ct state vmap { established:accept, related:accept, invalid:drop }
> 
> Is that "better" than the original?
> It's one less rule, so it ought to be more efficient, right?
> 
> One obvious downside is you lose the ability to counter/log/reject the
> ct state invalid packets, because those aren't valid in verdict_expr.
> 
> 
> Why is the original allowed to have "established,related" without braces?
> [UPDATE: answered below]
> 
> I'm a little bit worried because "nft describe ct state" looks like a
> list of flags (powers of two), and in parser_bison.y I don't understand
> ct_expr, but set_flag_list is using a comma as a bitwise OR.
> 
> Can a packet be *both* established and related at the same time?

'RELATED' is the first ('NEW') packet of a conn that has been determined to be related to an existing conn. As far as I know, once a conn transitions from 'RELATED' to 'ESTABLISHED', the system loses all knowledge that the conn was ever 'RELATED' in the first place. I mention this because I've never been able to determine if netfilter will close/terminate 'RELATED' conns when it closes/terminates the master. For example, if netfilter terminates an FTP control conn, does it also terminate data conns that were 'RELATED' to that control conn?


> 
> If so, is "ct state established,related" matching any packet that has
> established or related *OR BOTH*?
> 
> If so, does that mean it will accept some packets that my vmap (above) won't?
> 
> The parser won't accept "{related,established: accept}" in a vmap, but
> it will accept a pipe.  Does this has the same meaning as the original
> pair of rules?
> 
>     ct state vmap { invalid : drop, established | related : accept }
> 
> I think so, because the pipe comes back out as a comma here:
> 
>     # nft add rule 'inet x y ct state established|related accept'
>     # nft list chain inet x y
>     table inet x
>       chain y {
>         ct state established,related accept
>       }
>     }
> 
> Oh using the English word "or" is probably clearer, at least for
> anglophones:
> 
>     ct state established or related accept
>     ct state vmap { established or related: accept, invalid: drop }
> 
> The equivalence of "or" and "|" and "," --- except inside a set/map ---
> wasn't obvious to me from the nft manpage (as at 0.9.1).  I "caught on"
> because equivalences like "ne" and "!=" were mentioned here:
> https://wiki.nftables.org/wiki-nftables/index.php/Building_rules_through_expressions
> (no bitwise operators there, though)
> 
> 
> PS: AFAICT if a vmap doesn't match, the rule doesn't match, so
> processing just carries on to the next rule.  Is there a way to have a
> "default value" in the vmap?  e.g.
> 
>     ct state vmap { established or related: accept,
>                     new: continue,
>                     OTHERWISE: return }
> 
> I can't see it in verdict_map_list_expr or in the manpage.
> 
> PPS: my earlier "chain comment" question, I now realize the "NOOP rule"
> I wanted is just "continue", e.g.
> 
>     table inet x {
>       chain y {
>         continue comment "This chain is the common start for INPUT and FORWARD."
>         continue comment "It allows the things you (almost always) want."
>         ct state vmap { established or related: accept; invalid: drop }
>         iiftype loopback accept
>         icmp type { ... } accept
>         icmpv6 type { ... } accept
>       }
>     }
>