Correction to nftables wiki

Correction to nftables wiki

[Brian Pond]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

Dear Netfilter Team,

I would like to propose a correction to the following Wiki page.
https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_priority

After the code block, the following sentence reads:

"If priority of the 'input chain' above would be changed to -1, all
packets would be dropped. "

This sentence is incorrect.  All packets will be dropped, regardless of
the priority.  Because within the same hook, a "drop" action always
takes precedence over "accept".  Even if the "drop" is in a chain with
a later priority.

* I have attached an example illustrating this.  If you load this
ruleset with nft, browsing the web is impossible.  Regardless of
whatever priority value you choose.
* I have previously submitted a bug report about this behavior.  I
don't believe Netfilter was intended to work this way.

Either way, I feel the wiki should be updated for accuracy.  That way
readers understand how Netfilter is currently working, with regard to
drop and priority.

Please let me know if you have any questions.  I would be happy to
discuss further, meet online, etc.

Brian Pond


-- 
Brian Pond
Datahenge LLC
Business Software Consultant
Web: www.datahenge.com
Email: brian@datahenge.com
Tel: 509-808-3255


[-- Attachment #2: nftables_example.conf --]
[-- Type: text/plain, Size: 527 bytes --]

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    chain input {
        type filter hook input priority 0; policy accept;
    }

    chain ssh {
        type filter hook output priority 0; policy accept;
        tcp dport 80 accept;
        tcp dport 443 accept;
    }

    chain output {
        type filter hook output priority 15; policy drop;
        # Priority does not matter; outbound packets will *always* be dropped.
        # Drop is acting like a global, terminating action across the entire hook.
    }
}

Re: Correction to nftables wiki

[kfm]

Hi Brian,

On 30/12/2020 19:17, Brian Pond wrote:
> Dear Netfilter Team,
> 
> I would like to propose a correction to the following Wiki page.
> https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_priority
> 
> After the code block, the following sentence reads:
> 
> "If priority of the 'input chain' above would be changed to -1, all
> packets would be dropped. "
> 
> This sentence is incorrect.  All packets will be dropped, regardless of
> the priority.  Because within the same hook, a "drop" action always
> takes precedence over "accept".  Even if the "drop" is in a chain with
> a later priority.
> 
> * I have attached an example illustrating this.  If you load this
> ruleset with nft, browsing the web is impossible.  Regardless of
> whatever priority value you choose.
> * I have previously submitted a bug report about this behavior.  I
> don't believe Netfilter was intended to work this way.
> 
> Either way, I feel the wiki should be updated for accuracy.  That way
> readers understand how Netfilter is currently working, with regard to
> drop and priority.
> 
> Please let me know if you have any questions.  I would be happy to
> discuss further, meet online, etc.

See the following edit.

https://wiki.nftables.org/wiki-nftables/index.php?title=Configuring_chains&diff=610&oldid=534

-- 
Kerin Millar

Re: Correction to nftables wiki

[Brian Pond]

Thank you!  I think that edit will be extremely helpful for wiki
readers.

A special thanks for everyone's contributions to Netfilter and
nftables.  I've been working a lot on firewall tooling this past year.
It's been much easier (and better) using nftables versus the legacy
iptables system.

Happy New Year!
Brian Pond


On Wed, 2020-12-30 at 22:37 +0000, kfm@plushkava.net wrote:
> Hi Brian,
> 
> On 30/12/2020 19:17, Brian Pond wrote:
> > Dear Netfilter Team,
> > 
> > I would like to propose a correction to the following Wiki page.
> > https://wiki.nftables.org/wiki-
> > nftables/index.php/Configuring_chains#Base_chain_priority
> > 
> > After the code block, the following sentence reads:
> > 
> > "If priority of the 'input chain' above would be changed to -1, all
> > packets would be dropped. "
> > 
> > This sentence is incorrect.  All packets will be dropped,
> > regardless of
> > the priority.  Because within the same hook, a "drop" action always
> > takes precedence over "accept".  Even if the "drop" is in a chain
> > with
> > a later priority.
> > 
> > * I have attached an example illustrating this.  If you load this
> > ruleset with nft, browsing the web is impossible.  Regardless of
> > whatever priority value you choose.
> > * I have previously submitted a bug report about this behavior.  I
> > don't believe Netfilter was intended to work this way.
> > 
> > Either way, I feel the wiki should be updated for accuracy.  That
> > way
> > readers understand how Netfilter is currently working, with regard
> > to
> > drop and priority.
> > 
> > Please let me know if you have any questions.  I would be happy to
> > discuss further, meet online, etc.
> 
> See the following edit.
> 
> https://wiki.nftables.org/wiki-
> nftables/index.php?title=Configuring_chains&diff=610&oldid=534
> 

Re: Correction to nftables wiki

[G.W. Haywood]

Hi there,

On Wed, 30 Dec 2020, Brian Pond wrote:

> ... I've been working a lot on firewall tooling this past year.
> It's been much easier (and better) using nftables versus the legacy
> iptables system.

Do you think that you could jot down the main reasons that you've
found for the improvements?  Mail to the list would be fine for me.

I ask because I've found the change in syntax quite bewildering, and,
whenever I want to do more or less anything, most of the time I don't
even know where to start using nft commands so I find myself reverting
to iptables - because I can do that without really thinking about it,
and get the job done.  I don't know that I'd ever want to do anything
that I could do with nft that I couldn't do with iptables.  I don't
even know if there are such things, nor what those things might be.  I
have no clue if the things I do could be more efficient with nft.

If it will make any difference to your observations for my purposes,
typically I use just iptables and ipsets; a couple of dozen iptables
rules, for example

# iptables -L BLOCKSET --line-numbers
Chain BLOCKSET (1 references)
n  targ prot opt source   dest 
1  DROP tcp  --  anywhere anywhere match-set BLOCKSET08 src
2  DROP tcp  --  anywhere anywhere match-set BLOCKSET09 src
3  DROP tcp  --  anywhere anywhere match-set BLOCKSET10 src
4  DROP tcp  --  anywhere anywhere match-set BLOCKSET11 src
5  DROP tcp  --  anywhere anywhere match-set BLOCKSET12 src
6  DROP tcp  --  anywhere anywhere match-set BLOCKSET13 src
7  DROP tcp  --  anywhere anywhere match-set BLOCKSET14 src
8  DROP tcp  --  anywhere anywhere match-set BLOCKSET15 src
9  DROP tcp  --  anywhere anywhere match-set BLOCKSET16 src
10 DROP tcp  --  anywhere anywhere match-set BLOCKSET17 src
11 DROP tcp  --  anywhere anywhere match-set BLOCKSET18 src
12 DROP tcp  --  anywhere anywhere match-set BLOCKSET19 src
13 DROP tcp  --  anywhere anywhere match-set BLOCKSET20 src
14 DROP tcp  --  anywhere anywhere match-set BLOCKSET21 src
15 DROP tcp  --  anywhere anywhere match-set BLOCKSET22 src
16 DROP tcp  --  anywhere anywhere match-set BLOCKSET23 src
17 DROP tcp  --  anywhere anywhere match-set BLOCKSET24 src
18 DROP tcp  --  anywhere anywhere match-set BLOCKSET25 src
19 DROP tcp  --  anywhere anywhere match-set BLOCKSET26 src
20 DROP tcp  --  anywhere anywhere match-set BLOCKSET27 src
21 DROP tcp  --  anywhere anywhere match-set BLOCKSET28 src
22 DROP tcp  --  anywhere anywhere match-set BLOCKSET29 src
23 DROP tcp  --  anywhere anywhere match-set BLOCKSET30 src
24 DROP tcp  --  anywhere anywhere match-set BLOCKSET31 src
25 DROP tcp  --  anywhere anywhere match-set BLOCKSET32 src

and a few tens of thousands of ipset matches to DROP packets from the
more troublesome netblocks.  The ipsets are created by a boot script,
then (most of the time) populated automatically by a Sendmail milter
as mail is processed; for example when some joker tries to send HTTP
requests to the mail server his IP will be DROPped for a few days.

There are timeouts on most of the ipset entries.  The main issue I've
found is that there's an approximately 25 day limit on the timeout, so
if I want something longer I have to jump through some hoops, but it's
no big deal.

> Happy New Year!

The same to you, and all.

-- 

73,
Ged.

Re: Correction to nftables wiki

[Brian Pond]

Sure, here are some reasons I prefer nftables over iptables:

* No default tables and chains.  I prefer beginning with a "clean
slate" in nftables, and only defining elements I need.

* Atomic rule activation.  This was a huge improvement.  First, when
loading rules using 'nft -f', I'm now guaranteed my firewall isn't
briefly offline.  Peace of mind.

More importantly, I don't need to worry as much about "rollbacks."
With iptables, I had to implement custom code to snapshot the current
firewall state.  And then "rollback" if any single command failed. 
This is accomplished much-easier with nftables.

* I love the built-in support for configuration files (nftables.conf),
which can chain to other configuration files using the "include"
directive.  Accomplishing the same with iptables required a lot of
custom scripting.

* The ability to "log" and "drop" on the same rule line means fewer
rules.  So easier to read.

* The new "inet" tables mean I don't need to duplicate certain rules
for IPv4 and IPv6.

* Named Sets are fantastic.  I maintain lists of known bad IPs
(Blocklist), noisy neighbors and residents, and also known-good Package
Servers.  Storing these in sets means my filter rules are much, much
easier to read.  It also makes debugging easier, because I can quickly
check if an IP address belongs to one of my sets.

The past year, I've encountered a few nftables headaches.  But I've
resolve most of them.  For example, the Linux kernel that ships with
Debian 10 Buster does not fully support nftables.  So for every host I
work on, I've had to manually upgrade to a newer kernel.  Then verify
the NAT kernel module for nftables is loaded.

There are character limits on things like Table or Chain names.  So I
do some validation in scripts, prior to attempting to apply rules.

Currently I'm battling a 2017 issue reported by Jeff Kletsky, where my
NAT rules will not attached to an inet table.

"Error: NAT is only supported for IPv4/IPv6"
https://www.spinics.net/lists/netfilter/msg57571.html

To resolve this, I'll just split my NAT Prerouting table into IPv4 and
IPv6.

Hope this email was helpful!

~Brian Pond



On Thu, 2020-12-31 at 09:50 +0000, G.W. Haywood wrote:
> Hi there,
> 
> On Wed, 30 Dec 2020, Brian Pond wrote:
> 
> > ... I've been working a lot on firewall tooling this past year.
> > It's been much easier (and better) using nftables versus the legacy
> > iptables system.
> 
> Do you think that you could jot down the main reasons that you've
> found for the improvements?  Mail to the list would be fine for me.
> 
> I ask because I've found the change in syntax quite bewildering, and,
> whenever I want to do more or less anything, most of the time I don't
> even know where to start using nft commands so I find myself
> reverting
> to iptables - because I can do that without really thinking about it,
> and get the job done.  I don't know that I'd ever want to do anything
> that I could do with nft that I couldn't do with iptables.  I don't
> even know if there are such things, nor what those things might be. 
> I
> have no clue if the things I do could be more efficient with nft.
> 
> If it will make any difference to your observations for my purposes,
> typically I use just iptables and ipsets; a couple of dozen iptables
> rules, for example
> 
> # iptables -L BLOCKSET --line-numbers
> Chain BLOCKSET (1 references)
> n  targ prot opt source   dest 
> 1  DROP tcp  --  anywhere anywhere match-set BLOCKSET08 src
> 2  DROP tcp  --  anywhere anywhere match-set BLOCKSET09 src
> 3  DROP tcp  --  anywhere anywhere match-set BLOCKSET10 src
> 4  DROP tcp  --  anywhere anywhere match-set BLOCKSET11 src
> 5  DROP tcp  --  anywhere anywhere match-set BLOCKSET12 src
> 6  DROP tcp  --  anywhere anywhere match-set BLOCKSET13 src
> 7  DROP tcp  --  anywhere anywhere match-set BLOCKSET14 src
> 8  DROP tcp  --  anywhere anywhere match-set BLOCKSET15 src
> 9  DROP tcp  --  anywhere anywhere match-set BLOCKSET16 src
> 10 DROP tcp  --  anywhere anywhere match-set BLOCKSET17 src
> 11 DROP tcp  --  anywhere anywhere match-set BLOCKSET18 src
> 12 DROP tcp  --  anywhere anywhere match-set BLOCKSET19 src
> 13 DROP tcp  --  anywhere anywhere match-set BLOCKSET20 src
> 14 DROP tcp  --  anywhere anywhere match-set BLOCKSET21 src
> 15 DROP tcp  --  anywhere anywhere match-set BLOCKSET22 src
> 16 DROP tcp  --  anywhere anywhere match-set BLOCKSET23 src
> 17 DROP tcp  --  anywhere anywhere match-set BLOCKSET24 src
> 18 DROP tcp  --  anywhere anywhere match-set BLOCKSET25 src
> 19 DROP tcp  --  anywhere anywhere match-set BLOCKSET26 src
> 20 DROP tcp  --  anywhere anywhere match-set BLOCKSET27 src
> 21 DROP tcp  --  anywhere anywhere match-set BLOCKSET28 src
> 22 DROP tcp  --  anywhere anywhere match-set BLOCKSET29 src
> 23 DROP tcp  --  anywhere anywhere match-set BLOCKSET30 src
> 24 DROP tcp  --  anywhere anywhere match-set BLOCKSET31 src
> 25 DROP tcp  --  anywhere anywhere match-set BLOCKSET32 src
> 
> and a few tens of thousands of ipset matches to DROP packets from the
> more troublesome netblocks.  The ipsets are created by a boot script,
> then (most of the time) populated automatically by a Sendmail milter
> as mail is processed; for example when some joker tries to send HTTP
> requests to the mail server his IP will be DROPped for a few days.
> 
> There are timeouts on most of the ipset entries.  The main issue I've
> found is that there's an approximately 25 day limit on the timeout,
> so
> if I want something longer I have to jump through some hoops, but
> it's
> no big deal.
> 
> > Happy New Year!
> 
> The same to you, and all.
> 

Re: Correction to nftables wiki

[G.W. Haywood]

Hi Brian,

On Sat, 2 Jan 2021, Brian Pond wrote:

> * No default tables and chains. ...
> * Atomic rule activation.  ...
> * I love the built-in support for configuration files ...
> * The ability to "log" and "drop" on the same rule line ...
> * ... "inet" tables ... don't need to duplicate ... IPv4 and IPv6.
> * Named Sets ...

Thanks for that.  It seems that you and I use iptables very differently,
and that what's useful for you doesn't offer much to me.  Yes named sets
are great, but I use ipsets for the same reason and I have no complaints
about it apart from the timeout limitation which I think I've mentioned.
Otherwise, my firewall configurations don't usually change at all - from
one year to the next - so the dynamic aspects aren't an issue for me.

> ... a few nftables headaches ...

Only to be expected with new software, but the support is good.

I use Debian 10 or something derived from it on a bunch of machines,
but the firewalls aren't Debian, nor anything remotely like it.  There
are sets of (dynamic) iptables/ipsets rules on the individual (mostly
Debian-like) machines for specific purposes, like blocking SMTP and
HTTP attacks from China, and at the moment those rules do everything I
need with little effort from me now the scripting is all put to bed.
The main thing which exercises me is finding new ways to catch attacks
automatically; actually blocking them once identified is routine.

> Hope this email was helpful!

It was, very much so.  One of the things at the back of my mind was
that by being lazy I might be making some things harder for myself
than necessary, but you've reassured me a little on that score. :)

Thanks again Brian.

-- 

73,
Ged.