NetBSD-Bugs archive

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

Re: kern/53962: npf: weird 'stateful' behavior



The following reply was made to PR kern/53962; it has been noted by GNATS.

From: Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>
To: fstd.lkml%gmail.com@localhost
Cc: gnats-bugs%netbsd.org@localhost, tech-net%netbsd.org@localhost
Subject: Re: kern/53962: npf: weird 'stateful' behavior
Date: Sun, 17 Feb 2019 01:13:13 +0000

 fstd.lkml%gmail.com@localhost wrote:
 > Ok what seems to be going on is twofold:
 > 
 > <...>
 
 > Speaking of stateful-ends, when the direction-check is commented out, a
 > single 'stateful-ends' ingress rule gives me exactly the good old ipf
 > "keep state" behavior (if the packet is accepted into the filter, it's
 > implicitly permitted out of the filter, on whatever interface).  So
 > that's a workaround I can live with for now, although of course I'm not
 > entirely sure of the purpose of this direction check, or the consequences
 > of removing it.
 > 
 > Any insights?
 
 Thanks for a thorough summary.  Your (1) and (2) observations are correct.
 Basically, there are two points here:
 
 - NPF connection state is generally per-interface, but see below.  Bypassing
 the ruleset on other interfaces can have security implications, e.g. a packet
 with a spoofed IP address might bypass ingress filtering.  Hence the design
 decision to default to such behaviour (so you control what's happening on
 other interfaces with a ruleset there).
 
 - There are two keys for a connection (so that the reverse lookup on the
 returning packets would succeed).  It is necessary to establish the packet
 direction (with the respect to connection direction) for the full TCP state
 tracking.
 
 The "stateful-ends" mechanism is for having a global state (which could be
 picked up on other interfaces).  I think it should be fixed to assume that
 the packets on interface different than where the state was created should
 match the reverse key (for the "backwards stream"), without checking that
 it has the opposite interface-level direction.
 
 I'll have a look at this.
 
 -- 
 Mindaugas
 


Home | Main Index | Thread Index | Old Index