netfilter buglog - Jun 2020 - [Bug 1434] New: Usability improvements, enabling creation of complex firewalls

https://bugzilla.netfilter.org/show_bug.cgi?id=1434

            Bug ID: 1434
           Summary: Usability improvements, enabling creation of complex
                    firewalls
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: bugzillanetfilterorg at vespian.net

There is a community around iptables abstraction layer `Ferm`:
https://github.com/MaxKellermann/ferm

This tool is great when creating complex firewalls, and for e.g. integrating
firewall configuration with automation tools like Ansible. We would like to
switch to using nftables as this is the future, but there is still some
functionality gaps that prevent us from doing so.

In the following discussion: https://github.com/MaxKellermann/ferm/issues/35
there are quite a few good points made by the Ferm users, namely:
* from user horazont:
https://github.com/MaxKellermann/ferm/issues/35#issuecomment-486644235
* from user nurupo:
https://github.com/MaxKellermann/ferm/issues/35#issuecomment-644691310

I would like to bring this discussion to your attention and see if they could
be addressed. Thank you in advance for having a look and voicing your opinions. 

pr

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200618/4c57f7b9/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1434

sergio <sergio+it at outerface.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sergio+it at outerface.net

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200618/903125b0/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1434

kfm at plushkava.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kfm at plushkava.net

--- Comment #1 from kfm at plushkava.net ---
Disclaimer: I don't speak for the Netfilter team and any opinions expressed
are
my own. I think that some of the points being made are specious. I shall focus
on those particular points, which is not to imply that there aren't any
valid
points otherwise being made in the linked GitHub issue.

The claim that multiple layer 4 protocols cannot be matched is incorrect. This
is a valid rule:-

  meta l4proto { tcp, udp } th dport 53

There is no such thing as a "subchain". There are only chains, as
scoped by the
enclosing table, and they must be named. If there were even such a thing as an
anonymous chain then it wouldn't be possible to jump to it from a rule
defined
in another chain. This kind of abstraction is fine for an iptables/nftables
wrapper but doesn't translate well to the core.

One of the commenters presents the following ferm ruleset:

  domain (ip ip6) table filter {
    chain INPUT proto (tcp udp) dport 2003 {
      saddr ( 127.0.0.0/8 ::1/128 172.23.0.0/16 192.168.13.0/24 ) ACCEPT;
    }
  }

He proceeds to demonstrate an an equivalent ruleset for nftables that is unduly
convoluted. Yet, it could be written like this:-

  table inet filter {
    chain INPUT {
      meta l4proto { tcp, udp } th dport 2003 ip saddr { 127.0.0.0/8,
172.23.0.0/16, 192.168.13.0/24 } accept
      meta l4proto { tcp, udp } th dport 2003 ip6 saddr { ::1/128 } accept
    }
  }

Or this:-

  table inet filter {
    chain INPUT {
      meta l4proto { tcp, udp } th dport 2003 jump whitelist
    }
    chain whitelist {
      ip saddr { 127.0.0.0/8, 172.23.0.0/16, 192.168.13.0/24 } accept
      ip6 saddr { ::1/128 } accept
    }
  }

Note that this has the advantage of the "whitelist" chain being
referenceable
by any other rule. Even then, the problem is made to appear more complex than
it necessarily is. For instance, I might choose to write it like this:-

  table inet filter {
    chain INPUT {
      iifname "lo" accept
      meta l4proto { tcp, udp } th dport 2003 ip saddr { 172.23.0.0/16,
192.168.13.0/24 } accept
    }
  }

A claim is made to the effect that it is not trivial to atomically replace a
ruleset. In fact, all that is required is to begin with a flush ruleset
command. In the case that is considered undesirable to have the command be a
part of the stored ruleset, then it is only a matter of synthesizing the input
stream:-

  { echo "flush ruleset"; cat /path/to/ruleset.nft; } | nft -f -

Elsewhere, a complaint is made that nft "doesn't allow empty set
variables".
The following example is given:

  define BASE_ALLOWED_INCOMING_TCP_PORTS = {22, 80, 443}
  define EXTRA_ALLOWED_INCOMING_TCP_PORTS = {}
  table inet filter {
    chain input {
      type filter hook input priority 0; policy drop;
      tcp dport {$BASE_ALLOWED_INCOMING_TCP_PORTS,
$EXTRA_ALLOWED_INCOMING_TCP_PORTS} ct state new counter accept
    }
  }

However, I don't think that anyone in their right mind ought to go about it
in
such a way. Instead, they would be better served by using a named set:-

  table inet filter {
    set incoming_tcp_ports {
      type inet_service
      elements = { 20, 80, 443 }
    }    
    chain input {
      type filter hook input priority 0; policy drop;
      tcp dport @incoming_tcp_ports ct state new counter accept
    }
  }

Note that a named set doesn't have to contain any elements to begin with; it
can be declared with just the type alone. Unlike variables, they are properly
represented by the "list ruleset" command, rather than being elided.
Named sets
also have the advantage of being independently modifiable, among many other
things.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200826/18f611be/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1434

--- Comment #2 from kfm at plushkava.net ---
Another comment raises the complaint that it is not possible to write a single
rule that references multiple ports while having counters for each. This is now
incorrect, provided that a named set is used. For example:-

  table inet filter {
    set incoming_tcp_ports {
      type inet_service
      counter
      elements = { 20, 80, 443 }
    }    
    chain input {
      type filter hook input priority 0; policy drop;
      tcp dport @incoming_tcp_ports ct state new counter accept
    }
  }

Note the presence of the counter flag. To use this feature, both
nftables
>=0.9.5 and Linux >=5.7 are required.
-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200826/2a05ccb6/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1434

--- Comment #3 from kfm at plushkava.net ---
I think the point about having a feature that requires interactive input so as
not to revert the ruleset is a good one. I don't think it belongs in nft(8)
but
it wouldn't hurt to have a utility that is the equivalent of iptables-apply.
Such things should be filed as individual feature requests, ideally.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200826/73ba3072/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1434

kfm at plushkava.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.netfilter.
                   |                            |org/show_bug.cgi?id=1456

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200828/5f3d4be9/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1434

Pablo Neira Ayuso <pablo at netfilter.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #4 from Pablo Neira Ayuso <pablo at netfilter.org> ---
Regarding this one:
> https://github.com/MaxKellermann/ferm/issues/35#issuecomment-486644235
This patch will be available in the next nftables release. This requires a
kernel >= 5.9-rc1.

commit c330152b7f7779f15dba3e0862bf5616e7cb3eab
Author: Pablo Neira Ayuso <pablo at netfilter.org>
Date:   Sat Jul 4 02:43:44 2020 +0200

    src: support for implicit chain bindings

    This patch allows you to group rules in a subchain, e.g.

     table inet x {
            chain y {
                    type filter hook input priority 0;
                    tcp dport 22 jump {
                            ip saddr { 127.0.0.0/8, 172.23.0.0/16,
192.168.13.0/24 } accept
                            ip6 saddr ::1/128 accept;
                    }
            }
     }

    This also supports for the `goto' chain verdict.

BTW: Thanks for splitting this long report into several reports into
independent bugzilla tickets for easier tracking.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200828/9a255eca/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1434

--- Comment #5 from kfm at plushkava.net ---
That's impressive. Looking forward to seeing how it works.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200828/c6d52e24/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1434

kfm at plushkava.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.netfilter.
                   |                            |org/show_bug.cgi?id=1457

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200828/dd8b9a69/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1434

kfm at plushkava.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.netfilter.
                   |                            |org/show_bug.cgi?id=1458

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200828/c511ae75/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1434

kfm at plushkava.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.netfilter.
                   |                            |org/show_bug.cgi?id=1485

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20201201/ceb0bce7/attachment.html>