[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>
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
> 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
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.
Main Index |
Thread Index |