Re: Understanding output from "nft list"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 23 Aug 2024, at 11:50 PM, Brian Sammon wrote:
> Is there a document that is good for understanding the output of "nft 
> list"? (more specifically the kind of output that comes from "nfs list 
> ruleset")  In particular I'm looking for a description of the syntax.
>
> I've been browsing around https://www.netfilter.org/ and I've been 
> having trouble finding the kind of information that I'm looking for.

There is no formal definition of the grammar beyond the source code itself, and no good documentation for the grammar beyond that which can be cobbled together from reading https://netfilter.org/projects/nftables/manpage.html and the wiki. I would say that experimentation also helps.

>
> The first questions I have:
> Can/should I assume that each line in the output of "nft list" is a 
> separate, uh... "thing"[1] that can be (human-)parsed independently 
> from every other line?

No, though it is possible to compose rulesets in the iptables-esque fashion that you imply. That is, by writing consecutive commands of the form of "add table", "add chain", "add rule" and so forth. However, the nft(8) utility does not have an option to list the loaded ruleset in that way. Instead, it always lists the ruleset in the declarative style.

> Is there something that signifies "this line 
> should be considered as part of the same Thing as the last/next line"?

Depending on what you mean, the fact that it is enclosed by the same pair of curly braces.

# A table (a namespace, really).
table inet t {
    # A chain contained by said table.
    chain c1 {
        # There may be rules contained by this chain.
    }
    # Another chain contained by said table.
    chain c2 {
        # There may also be rules contained by this chain.
    }
}

That could also have been written as the following command sequence:

add table inet t
add chain inet t c1
add chain inet t c2

Commands and statements may be line-continued by way of backslash-escaping the newline that would otherwise terminate them.

# This is a single rule.
meta l4 proto tcp dport { 80, 443 } accept

# And so is this.
meta l4 proto tcp \
    dport { 80, 443 } accept

>
> Should I be reading each line/"thing" from left to right in my attempt 
> to parse/understand it?

To say forwards would be more accurate. In several respects, the syntax is not entirely unlike that of the shell:

- whitespace generally serves only to separate tokens unless quoted
- newlines are metacharacters unless demoted to mere whitespace by being quoted (escaped)
- semicolons have the same effect as raw newlines
- upon encountering an opening curly brace, the parser must look for its closing counterpart

> This is complicated by the fact that the current firewall config is 
> generated by a "front end" package, which I'm also trying to learn.
> I wonder if the output from "nft list" represents some weird syntax 
> generated by the front end package.  Can I assume that the output of 
> "nft list" is _valid_ syntax?

Always, unless it happens to be a hybrid ruleset produced by iptables-nft(8). See https://www.redhat.com/en/blog/using-iptables-nft-hybrid-linux-firewall. If you instruct nft(8) to list a hybrid ruleset, it will include the following diagnostic message as part of its output.

# Warning: table ip filter is managed by iptables-nft, do not touch!

>
> [1] - I'm not sure if "expression", "statement", or "rule", or 
> something else, is an appropriate word to use here.

Such is understandable. Even as an experienced nftables user, it is difficult to explain using strictly formal terminology.

-- 
Kerin Millar




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux