Waiting until first release of NFTABLES

Waiting until first release of NFTABLES

[Stephen Satchell]

I'm concerned that Centos 8 is using a pre-release version of nftables. 
I just did a system update, and found this as current:

/etc/redhat-release:  CentOS Linux release 8.1.1911 (Core)
$ nft -v:             nftables v0.9.0 (Fearless Fosdick)

I think that, given some of the issues that have been mentioned on this 
list, I'm not comfortable with this new pre-release facility.  So I'll 
wait until it reaches v1.0 or higher, and in the meantime revert to 
using IPTABLES and my home-brew shell script, disabling firewalld(8) in 
the process.

To ensure BGP-38 compliance upstream, I'll use the routing table 
extension that I have developed for NetworkManager, that I posted 
earlier, that null-routes all reserved netblocks.  (I'm not planning to 
incorporate the BOGON enhancement as suggested by others.)

The following will appear in my /etc/sysctl.conf file, which turns on 
source filtering and logs martians.

  net.ipv6.conf.all.disable_ipv6  = 1
  net.ipv4.conf.all.rp_filter = 1
  net.ipv4.conf.all.log_martians = 1

  net.ipv6.conf.default.disable_ipv6 = 1
  net.ipv4.conf.default.rp_filter = 1
  net.ipv4.conf.default.log_martians = 1

Yes, this means that I'm blocking all ipv6 for now.  I will reconsider 
as the 1.0 or later release version makes it to the CentOS 8 distribution.

Re: Waiting until first release of NFTABLES

[Trent W. Buck]

Stephen Satchell <list@satchell.net> writes:

> I'm concerned that Centos 8 is using a pre-release version of
> nftables. I just did a system update, and found this as current:
>
> /etc/redhat-release:  CentOS Linux release 8.1.1911 (Core)
> $ nft -v:             nftables v0.9.0 (Fearless Fosdick)

You might want to look for other installed packages < 1.0.0:

    rpm -qa --qf '%{name} %{version}-%{release}\n' |
    sort --sort=version --key=2

It's... not uncommon. :-)
On my laptop, fully 20% of packages are below version 1.

> To ensure BGP-38 compliance upstream, I'll use the routing table
> extension that I have developed for NetworkManager, that I posted
> earlier, that null-routes all reserved netblocks.  (I'm not planning
> to incorporate the BOGON enhancement as suggested by others.)

I think you mean BCP-38:
https://tools.ietf.org/html/bcp38

> The following will appear in my /etc/sysctl.conf file, which turns on
> source filtering and logs martians.
>
>  net.ipv6.conf.all.disable_ipv6  = 1
>  net.ipv4.conf.all.rp_filter = 1
>  net.ipv4.conf.all.log_martians = 1
>
>  net.ipv6.conf.default.disable_ipv6 = 1
>  net.ipv4.conf.default.rp_filter = 1
>  net.ipv4.conf.default.log_martians = 1
>
> Yes, this means that I'm blocking all ipv6 for now.  I will reconsider
> as the 1.0 or later release version makes it to the CentOS 8
> distribution.

CentOS runs systemd, so rp_filter=1 (or =2 since v240) should be on by default:
https://github.com/systemd/systemd/blob/master/sysctl.d/50-default.conf

Re: Waiting until first release of NFTABLES

[Stephen Satchell]

On 2/23/20 4:58 PM, Trent W. Buck wrote:
> CentOS runs systemd, so rp_filter=1 (or =2 since v240) should be on by default:

"CentOS Linux release 8.1.1911 (Core)"  has this line:> 
net.ipv4.conf.all.rp_filter = 1

rp_filter is indeed '1'
log_martians is '0'

Since I want rp_filter=1 instead of 2 (I'm not multi-homed) I'll do the 
override according to the documentation; specifically, I'll add my 
overrides to /etc/sysctl.d/99-sysctl.conf -- then I'll check to see that 
the two kernel knobs are set correctly for all interfaces.

And, yes, I meant BCP-38.

As for other packages with version numbers of 0.x, I'm not all that 
concerned in a firewall router for anything except the firewall facility 
itself.  This router will have, as its sole job, filtering incoming and 
outgoing packets to my upstream.

Thank you for your comments.

Re: Waiting until first release of NFTABLES

[Reindl Harald]

Am 24.02.20 um 06:02 schrieb Stephen Satchell:
> As for other packages with version numbers of 0.x, I'm not all that
> concerned in a firewall router for anything except the firewall facility
> itself.  This router will have, as its sole job, filtering incoming and
> outgoing packets to my upstream.

1.0 vesions in the opensource world typically stand for "feature
complete" and you couldn't care less about features developers are
planning when you don't miss and use them


besides that "nftables" is not the "firewall facility itself", it's the
package with the userland tools

the kernel does the filtering and has no version 0.9 for decades

Re: Waiting until first release of NFTABLES

[Stephen Satchell]

On 2/24/20 1:25 AM, Reindl Harald wrote:
> 
> 
> Am 24.02.20 um 06:02 schrieb Stephen Satchell:
>> As for other packages with version numbers of 0.x, I'm not all that
>> concerned in a firewall router for anything except the firewall facility
>> itself.  This router will have, as its sole job, filtering incoming and
>> outgoing packets to my upstream.
> 
> 1.0 vesions in the opensource world typically stand for "feature
> complete" and you couldn't care less about features developers are
> planning when you don't miss and use them
> 
> 
> besides that "nftables" is not the "firewall facility itself", it's the
> package with the userland tools
> 
> the kernel does the filtering and has no version 0.9 for decades

"A chain is as strong as its weakest link."  libnftables.c doesn't carry 
a version number in its source, so I don't know what release level it's at.

One thing I would love is a way of injecting packets into a userland 
test tool that reports what nftables did with it.  If I had such a tool, 
I would be more inclined to use a 0.x version because I could verify 
that the code plus ruleset is doing what it's supposed to do.

Yes, I know that a number of IP et al filters don't have a quality check 
feature.  (Run into this all the time with Cisco routers, for example.)

Re: Waiting until first release of NFTABLES

[Trent W. Buck]

Stephen Satchell <list@satchell.net> writes:

> One thing I would love is a way of injecting packets into a userland
> test tool that reports what nftables did with it.  If I had such a
> tool, I would be more inclined to use a 0.x version because I could
> verify that the code plus ruleset is doing what it's supposed to do.

Can't you use "ip netns" (or systemd-nspawn, or docker, or libvirt-qemu)
to set up a test network with a test firewall, then send packets into /
out of that test environment?

OK, it's a bit fiddly to set up, but I don't see why you need any
special nftables-specific thing when you can just do regular
namespace/container/vm techniques.

Re: Waiting until first release of NFTABLES

[Stephen Satchell]

On 2/24/20 5:12 PM, Trent W. Buck wrote:
> Can't you use "ip netns" (or systemd-nspawn, or docker, or libvirt-qemu)
> to set up a test network with a test firewall, then send packets into /
> out of that test environment?
> 
> OK, it's a bit fiddly to set up, but I don't see why you need any
> special nftables-specific thing when you can just do regular
> namespace/container/vm techniques.

HOWTO link?

Re: Waiting until first release of NFTABLES

[Trent W. Buck]

Stephen Satchell <list@satchell.net> writes:

> On 2/24/20 5:12 PM, Trent W. Buck wrote:
>> Can't you use "ip netns" (or systemd-nspawn, or docker, or libvirt-qemu)
>> to set up a test network with a test firewall, then send packets into /
>> out of that test environment?
>>
>> OK, it's a bit fiddly to set up, but I don't see why you need any
>> special nftables-specific thing when you can just do regular
>> namespace/container/vm techniques.
>
> HOWTO link?

I don't have one, but this is a basic introduction to "ip netns":
https://lwn.net/Articles/580893/

Once the netns is set up, you'd do something like

    ip netns exec my-cool-namespace  nft --file=my-cool-firewall.nft
    ip netns exec my-cool-namespace  firefox gopher://porn.example.edu

Then look at nft's counters (add rule ... counter accept), or
kernel logs (add rule ... log accept), or
whatever diagnostics you normally do.

The fiddly part is turning that into a turnkey "solution" that can have
multiple namespaces hooked up to one another, and to the real internet.

Re: Waiting until first release of NFTABLES

[Stephen Satchell]

On 2/19/20 3:41 PM, Stephen Satchell wrote:
> I'm concerned that Centos 8 is using a pre-release version of nftables. 

So, with China starting to ramp up its network penetration, I'm going to 
set aside CentOS 8 and instead bring up Centos 7.6 and continue to use 
IPTABLES with my existing ruleset, with my BCP-38 addition to 
NetworkManager plus turning on rp_filter.

Once the NFTABLES project reached 1.0 or so (wait for 1.1?) and it's in 
the CentOS 8 respositories, I can spin up a CentOS 8 instance and start 
experimenting.

Re: Waiting until first release of NFTABLES

[Reindl Harald]

Am 13.03.20 um 23:05 schrieb Stephen Satchell:
> On 2/19/20 3:41 PM, Stephen Satchell wrote:
>> I'm concerned that Centos 8 is using a pre-release version of nftables. 
> 
> So, with China starting to ramp up its network penetration, I'm going to
> set aside CentOS 8 and instead bring up Centos 7.6 and continue to use
> IPTABLES with my existing ruleset, with my BCP-38 addition to
> NetworkManager plus turning on rp_filter.
> 
> Once the NFTABLES project reached 1.0 or so (wait for 1.1?) and it's in
> the CentOS 8 respositories, I can spin up a CentOS 8 instance and start
> experimenting.

you still don't understand versioning of opensource and the linux kernel
at all! the parts which are doing *really* the work don't have anything
to do with the userland tool because they are part of the kernel