** Reply to message from Trevor Talbot [EMAIL PROTECTED] on Fri, 7 Jan
2005 04:35:36 -0800
On Thursday, Jan 6, 2005, at 16:21 US/Pacific, Jason Murray wrote:
If I understand things properly when the packet comes in on $ext_if it
creates the state. Because the state is floating it should be picked
up when the packet tries to go out on $uat_if. Since it is in the
state table it should pass no problem.
Though the state is floating with respect to interfaces, the
_direction_ is still locked. It sees that out.side.add.ress sent a
packet IN to in.side.web.server, and so will only match future packets
with that address pair if they are also coming IN. (And packets OUT
for the reverse address pair, of course.) The floating part just
means it doesn't care what interface that happens on.
This particular point seems to have gotten lost in the documentation
since the if- and group-bound options were introduced.
I've no knowledge of PF's internals and am not a firewall guru, but
this seems strange to me -- I'd have expected state floated to another
interface to lock in the *reverse* direction since (at least in what
I'd think of as the common cases) packets which are inbound on one
interface will be outbound on any other interface they traverse (and
vice versa). I suppose that in cases where, for redundancy, multiple
interfaces operate more or less in parallel locking in the same
direction makes sense; this seems to me like a *much* less common
setup, though if packets for the same state could traverse any of those
interfaces a floating state with the same direction might be the only
way to properly configure the firewall.
Hmmm. For a firewall properly protected against IP address spoofing,
there's only one possible direction on each interface for an allowed
packet with any given source (or destination) IP address. Perhaps
states shouldn't include direction information at all? But this would
require that anti-spoofing rules be processed *before* state lookup
which would require major changes to PF and might significantly slow
down processing.
I hadn't realized it until I started thinking this through, but it
appears that, if floating state is enabled, there's no way to prevent
PF from passing *some* spoofed packets -- though this probably isn't a
significant issue in practice. Perhaps the right way to deal with
all of these issues is to provide more explicit control over floating
state -- e.g., eliminate the current general floating state and add to
each rule specifying keep state (or its relatives) an optional list
of interfaces to which those states may float with a direction for each
such interface.
If this doesn't make sense, I'd appreciate a brief explanation (or
pointer to one) of what false assumptions or inferences I've made and
why they're false.
Dave
--
Dave Anderson
[EMAIL PROTECTED]
