netfilter buglog - Dec 2018 - [Bug 1305] New: Rules in second chain same hook ignored if first chain has policy drop

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

            Bug ID: 1305
           Summary: Rules in second chain same hook ignored if first chain
                    has policy drop
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: Debian GNU/Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: keithwilliamsnp at gmail.com

Debian Stretch, nft version 0.9.0-1 kernel 4.9.0-8-amd64

Am finding behaviour in added chains a bit different to that expected from
reading all the documentation.

I have chain 

input {type filter hook input priority 0; policy drop;} 

This carried most of the firewall rules. I then added another
chain

testpr {type filter hook input priority -1;}

I cut and pasted the rule to accept ftp from the input chain (where it had been
working) into the testpr chain. 
ftp was blocked. The packets should have traversed testpr first, been accepted
before, if necessary entering input chain. This was obviously not happening.
I tried swapping the priorities which, as expected, put the testpr chain after
the input chain and so caused the ftp packets to be dropped.
The only way I could get it to work was to change the input policy, but then,
of course, that gave a policy of accept so the testpr chain was irrelevant. As
any packet not specifically dropped would be accepted, defeating the purpose of
a firewall.
I had the same result after changing the testpr to a non-base chain.

-- 
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/20181201/0af11f9c/attachment.html>

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

keithwilliamsnp at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Rules in second chain same  |Rules in first chain same
                   |hook ignored if first chain |hook ignored if second
                   |has policy drop             |chain has policy drop

-- 
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/20181201/a82827b6/attachment.html>

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

Florian Westphal <fw at strlen.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fw at strlen.de

--- Comment #1 from Florian Westphal <fw at strlen.de> ---
(In reply to keithwilliamsnp from comment #0)
> Debian Stretch, nft version 0.9.0-1 kernel 4.9.0-8-amd64
> 
> Am finding behaviour in added chains a bit different to that expected from
> reading all the documentation.
> 
> I have chain 
> 
> input {type filter hook input priority 0; policy drop;} 
> 
> This carried most of the firewall rules. I then added another
> chain
> 
> testpr {type filter hook input priority -1;}
> 
> I cut and pasted the rule to accept ftp from the input chain (where it had
> been working) into the testpr chain. 
> ftp was blocked. The packets should have traversed testpr first, been
> accepted before, if necessary entering input chain. This was obviously not
> happening.
Yes, this is the same as e.g. accepting in iptables mangle table input chain --
the packet will continue to filter table input.

I'll leave this open for now, any suggestion on where to place this in the
documentation?

-- 
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/20190714/483dd1d3/attachment.html>

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

david at hajes.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david at hajes.org

--- Comment #2 from david at hajes.org ---
I am having similar problem. it looks like priority of chains doesn't work.

I have following hooks:

filter input prio 0

nat prerouting prio -500


nat prerouting gets ignored, despite it has got higher priority than normal
input chain and rules in filter input are carried out instead

-- 
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/20200119/e729b2a4/attachment.html>

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

--- Comment #3 from Brian Pond <brian at pondconsulting.net> ---
Created attachment 602
  --> https://bugzilla.netfilter.org/attachment.cgi?id=602&action=edit
Script demonstrating conflicting base chains.

-- 
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/20200805/d2b40ceb/attachment.html>

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

Brian Pond <brian at pondconsulting.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brian at pondconsulting.net

--- Comment #4 from Brian Pond <brian at pondconsulting.net> ---
Comment on attachment 602
  --> https://bugzilla.netfilter.org/attachment.cgi?id=602
Script demonstrating conflicting base chains.

I am unsure whether this is a "bug" or "working as
intended".  But I have
encountered a similar situation as the OP.

Script attached showing how to duplicate.  There are 2 base chains for
filter+output.  
* The first chain allows outbound HTTP/HTTPS.  
* The second chain has a default policy of "drop".  

If you apply these rules, you cannot access the web through your browser.
>From a certain point of view, this seems to contradict documentation. 
Documentation says that "accept" is a terminating statement.  The
first chain
is lower priority, so should be evaluated first.  Once the outbound HTTP/HTTPS
is accepted, it should not be re-evaluated by the 2nd chain, and dropped.

What I "think" the documentation should say is this:

1) "If you create 2+ base chains for the same hook, all chains are
evaluated."
2) "Accept is a terminating statement, but only within its own base
chain."
3) "Drop is a terminating statement globally.  It will override decisions
by
other base chains of the same hook."

Whether this is what the maintainers intended or not, I don't know.

My workaround was creating non-base chains, and doing jumps.  I'm kind of
disappointed about that.  I'd hoped to avoid jumps altogether, by creating
multiple base chains of different priorities.  With my final base chain being
"log drop".  This way, if traffic is not explicitly allowed, it is
logged and
dropped.

My ruleset is working fine now, but it's not quite-as-clean as I'd
hoped.

-- 
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/20200805/3586a7c2/attachment.html>

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

Marcos de Oliveira <markinholiveira at gmail.com> changed:

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

-- 
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/20200923/8bfafc73/attachment.html>

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

Egbert S <s.egbert at sbcglobal.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |s.egbert at sbcglobal.net

--- Comment #5 from Egbert S <s.egbert at sbcglobal.net>
---
> I have following hooks:
> 
> filter input prio 0
> 
> nat prerouting prio -500
The priority values only works within the same hook.  There are 6 hooks
(ingress, prerouting, input, forward, output, postrouting).

                                             Local
                                            process
                                              ^  |      .-----------.
                   .-----------.              |  |      |  Routing  |
                   |           |-----> input /    \---> |  Decision
|---->
output \
--> prerouting --->|  Routing  |                        .-----------.
   \
                   | Decision  |                                               
     --> postrouting
                   |           |                                               
    /
                   |           |---------------> forward
--------------------------- 

Don't forget to add 'ingress' before `prerouting` to the old chart
above.
Ingress was added in Linux 4.2.


This is what I've gathered from the current Netfilter Wiki on nftables.

If many different chains exist within and only within that one `ingress` hook,
these chains ordered as each priority states, from lowest value (-500) to
highest value (+500) in terms of packet examination ordering.

If only just the two same-named chains but in different hooks (i.e., input,
forward) of different priority, priority settings don't matter.

Hook is the FIRST thing encountered when deciding the priority of chains within
each of the 6 hooks, next is within each chain that its rules' antecedence
and
precedence are done in insertion order.

Your example is spread across two separate hooks (input & prerouting): so
your
example of priority don't matter on this point.

-- 
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/20201007/cd782141/attachment.html>

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

--- Comment #6 from Egbert S <s.egbert at sbcglobal.net> ---
Updated diagram:
https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks

-- 
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/20201007/f69efc79/attachment.html>

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

Marcos de Oliveira <markinholiveira at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markinholiveira at gmail.com

--- Comment #7 from Marcos de Oliveira <markinholiveira at gmail.com> ---
(In reply to Egbert S from comment #5)
> > I have following hooks:
> > 
> > filter input prio 0
> > 
> > nat prerouting prio -500
> 
> The priority values only works within the same hook.
True, but that's not so useful, as later chains can't have a drop
policy.
If you accept a packet in a chain, it will continue evaluating against other
chains of higher priority in the same hook. So if other chains have a policy of
drop, your accepted packet gona get dropped.

That's something hard to change, as it would break lots of users's
implementations. But, we could get new options added to implement better logic,
as I suggested in #1471.

As currently we have an "drop" verdict, which is applied immediately,
and an
"accept", which continue evaluating in same hook against other
chains's rules,
I suggested "quick-accept" which would act as current's drop and
stop
evaluating other chains in current hook, and a "delayed-drop", which
will drop
packet only at the end of current hook. This way, no user implementation would
break.

Apart from being two new verdicts, it could also be implemented as two keywords
instead (quick and delay), so you could use it interchangeably (delay accept,
quick drop, with proper policy actions).

-- 
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/20201015/dc473610/attachment.html>

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

Marcos de Oliveira <markinholiveira at gmail.com> changed:

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

-- 
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/20201015/b10a05eb/attachment.html>

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

Timo Weing�rtner <timo at tiwe.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timo at tiwe.de

--- Comment #8 from Timo Weing�rtner <timo at tiwe.de> ---
You can have this quick-accept and delayed-drop behaviour if you create only
one base chain and branch off to other chains from there (the same worked with
classic iptables):

table inet filter {
  chain forward {
    type filter hook forward priority filter
    ct state established accept
    iifname "internal" accept
    iifname "world" tcp dport ssh jump ssh-in
    iifname "world" tcp dport https jump https-in
    # this could be policy, but I like to make it explicit:
    drop
  }
  chain ssh-in {
    ip6 daddr 2001:db8::2a accept
    ip6 daddr 2001:db8::539 accept
    ip daddr 192.0.2.42 accept
  }
  chain https-in {
    ip6 daddr 2001:db8::1267 accept
  }
}

If you want to carry complex decisions made earlier to other base chains you
can use a mark.

Maybe I misunderstand your goal or use case? Why do you want to have separate
base chains if you do not want them to independently drop a packet?

-- 
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/20210120/04e6f7db/attachment.html>

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

--- Comment #9 from Brian Pond <brian at pondconsulting.net> ---
"Why do you want to have separate base chains if you do not want them to
independently drop a packet?"

Because I want my separate base chains to independently -accept- a packet.

Your workaround is practical.  I'm doing the same thing in my production
environments today.  By using a single base chain, plus jumps to non-base
chains, I can achieve the desired behavior.  I want my nftables to Log and Drop
everything by default.  Except for packets I have explicitly Safelisted.

However, the design could be even simpler.  If I could create multiple Base
Chains, with different Priorities, I could avoid writing Jump statements
altogether:

* Base Chain #1, Priority 0 = Accept Some Things.
* Base Chain #2, Priority 10 = Accept Some Things.
* Base Chain #3, Priority 20 = Accept Some Things.
* Base Chain #4, Priority 30 = Log and Drop Everything Else.

In this way, a packet flows linearly through the rules based on chain priority.
 Until it's either Accepted or Dropped.  First match wins.  I wouldn't
need to
code Jumps at all.

Currently this is impossible, because that final Drop in Base #4 overrules the
previous 3 chain's decisions.  

And Priority is left without any real purpose.  I'm practically limited to 1
base chain per hook.  Whether those chains are Priority 0 or 200, all that
actually matters is jumping around, until the packet encounters a Drop.

-- 
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/20210120/0a5bf62b/attachment.html>

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

--- Comment #10 from Marcos de Oliveira <markinholiveira at gmail.com> ---
(In reply to Timo Weing�rtner from comment #8)
> You can have this quick-accept and delayed-drop behaviour if you create
only
> one base chain and branch off to other chains from there (the same worked
> with classic iptables):
> 
> table inet filter {
>   chain forward {
>     type filter hook forward priority filter
>     ct state established accept
>     iifname "internal" accept
>     iifname "world" tcp dport ssh jump ssh-in
>     iifname "world" tcp dport https jump https-in
>     # this could be policy, but I like to make it explicit:
>     drop
>   }
>   chain ssh-in {
>     ip6 daddr 2001:db8::2a accept
>     ip6 daddr 2001:db8::539 accept
>     ip daddr 192.0.2.42 accept
>   }
>   chain https-in {
>     ip6 daddr 2001:db8::1267 accept
>   }
> }
> 
> If you want to carry complex decisions made earlier to other base chains
you
> can use a mark.
> 
> Maybe I misunderstand your goal or use case? Why do you want to have
> separate base chains if you do not want them to independently drop a
packet?
It would be much more convenient if we could use nftables priorities... There
are many tools that use iptables/nftables for managing nat/routing, like LXD,
docker, libvirt. If we could accept packets early in the packet processing, we
could have the flexibility to accept a packet and not care if other chains have
a policy of drop. Also, nftables and iptables would coexist easier, as we could
create a chain of lower priority than iptables's and still have policy of
DROP
in iptables INPUT chain for example. It would be more clean also, less jumps
between chains.

-- 
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/20210121/56af85de/attachment.html>

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

Alexander.S <bugz at dragon-home.dyndns-mail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugz at dragon-home.dyndns-mai
                   |                            |l.com

--- Comment #11 from Alexander.S <bugz at dragon-home.dyndns-mail.com> ---
(In reply to Egbert S from comment #5)
> 
> The priority values only works within the same hook.  There are 6 hooks
> (ingress, prerouting, input, forward, output, postrouting).
> 
>                                              Local
>                                             process
>                                               ^  |      .-----------.
>                    .-----------.              |  |      |  Routing  |
>                    |           |-----> input /    \---> |  Decision
|----> output \
> --> prerouting --->|  Routing  |                        .-----------.
\
>                    | Decision  |                                           
--> postrouting
>                    |           |                                           
/
>                    |           |---------------> forward
---------------------------
> 
> Don't forget to add 'ingress' before `prerouting` to the old
chart above.
> Ingress was added in Linux 4.2.
> 
This is the wrong picture: output is actually _before_ routing!

-- 
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/20210121/edf3eca9/attachment.html>

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

Frank Myhr <fmyhr at fhmtech.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fmyhr at fhmtech.com

--- Comment #12 from Frank Myhr <fmyhr at fhmtech.com> ---
@Alexander S.: I think the packet flow diagram posted by Egbert S. is correct,
i.e. output hook comes *after* routing decision. As is also shown here:
https://commons.wikimedia.org/wiki/File:Netfilter-packet-flow.svg

As to Marco's proposal of quick-accept and delayed-drop statements: neat
idea.
As pointed out, they would make hook priority more powerful than it currently
is. But as Brian points out, when using nftables only (no legacy iptables
stuff), then the same effect can be achieved with a single base chain (hook)
using multiple jump (or goto) statements. For this case, I wonder how the
computational efficiency of multiple jumps vs. multiple hooks compares? Maybe
the single base chain with multiple jumps is more efficient, if less elegant,
than multiple base chains?

In cases where legacy iptables stuff is in simultaneous use, I agree that the
proposed quick-accept / delayed-drop additions would make the combined policy
far less confusing than it currently is.

-- 
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/20210206/23c7eb9e/attachment.html>

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

--- Comment #13 from Frank Myhr <fmyhr at fhmtech.com> ---
Created attachment 623
  --> https://bugzilla.netfilter.org/attachment.cgi?id=623&action=edit
netfilter / nftables packet flow diagram

My understanding of netfilter / nftables packet flow. (Tangential topic here I
know, so feel free to send suggestions / corrections via email instead of this
bug report.)

-- 
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/20210206/4e58ebce/attachment.html>

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

--- Comment #14 from Alexander.S <bugz at dragon-home.dyndns-mail.com> ---
(In reply to Frank Myhr from comment #12)
> @Alexander S.: I think the packet flow diagram posted by Egbert S. is
> correct, i.e. output hook comes *after* routing decision. As is also shown
> here:
> https://commons.wikimedia.org/wiki/File:Netfilter-packet-flow.svg
> 
Please notice the "reroute check" after the "output".
Otherwise, "DNAT" and
"mark set" for PBR will not work for outgoing packets.
Also, see http://people.netfilter.org/pablo/docs/login.pdf

-- 
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/20210206/aab48740/attachment.html>

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

Frank Myhr <fmyhr at fhmtech.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #623 is|0                           |1
           obsolete|                            |

--- Comment #15 from Frank Myhr <fmyhr at fhmtech.com> ---
Created attachment 624
  --> https://bugzilla.netfilter.org/attachment.cgi?id=624&action=edit
slightly-more-correct? nftables packet flow diagram

Comments / corrections appreciated :-)

-- 
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/20210206/898e610b/attachment.html>

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

--- Comment #16 from Frank Myhr <fmyhr at fhmtech.com> ---
@ Alexander.S: Thanks for that ref, it's a good read. I'm still unsure
of
order/relationship between output and routing. Funny you should mention marking
packets/DNAT in output chain, I've never gotten that to work (admittedly
tried
only with older kernels / iptables).

About the proposed quick-accept verdict: on further reflection, such a change
would seem to require a change to the way netfilter (not just nftables) works.
As Pablo writes in the login article that Alexander.S linked, conntrack
registers callbacks to the same netfilter hooks that nftables and iptables do.
(Maybe there are additional facilities that register yet more callbacks to
these hooks?) Netfilter's general hook-and-callback system means that even
if
from the point of view of your nft ruleset that *firewall* operations are
finished for a given netfilter hook, and you'd like to quick-accept, there
might be conntrack or other callbacks registered to that hook that still need
to be performed. So netfilter's flexibility in allowing multiple systems to
use
its hooks may come at the price of disallowing such quick-accept...? It seems
what would be needed is a filter-only quick-accept, while still running any
non-filter callbacks at that hook. Which sounds like it might be more trouble
than it's worth, when the same can be achieved with jumps within a single
filter callback.

-- 
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/20210206/4507039e/attachment.html>

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

--- Comment #17 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to Frank Myhr from comment #13)
> Created attachment 623 [details]
> netfilter / nftables packet flow diagram
> 
> My understanding of netfilter / nftables packet flow. (Tangential topic
here
> I know, so feel free to send suggestions / corrections via email instead of
> this bug report.)
I have just updated the wiki page, please see:

https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks
https://people.netfilter.org/pablo/nf-hooks.png

Let me know if you have comments on this one / find mistakes to fix this.

Routing comes before the output hook, that's why there is a 'route'
chain type
for output basechains.

-- 
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/20210208/c35d125f/attachment.html>