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

Re: Strange ? keep state behaviour



On Fri, Jan 07, 2005 at 11:06:18AM -0500, Dave Anderson wrote:
> 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.
Adding to the previous explanation, if you know that one side of the
connection should pass only through one specific interface (like a
single uplink interface), you should use an if-bound state for that
side. There's no reason to use a floating state in that case.
If you're using a floating state (maybe just because it's the default,
and you didn't realize the difference), there is one form of spoofing
that becomes possible:
The state entry says:
  on any interface, pass incoming from A to B, outgoing from B to A
Such packets should only occur on interface I, but you made the state
floating (instead of if-bound to I), so theoretically, someone might
inject a packet on another interface (not I), like
  incoming from A to B on J
  outgoing from B to A on K
but NOT
  incoming from B to A on L
  outgoing from A to B on K
because the state will only match the former two, but not the latter
two.
Now, to successfully match a state entry, an attacker needs to know (or
guess) more than just the source and destination addresses. For TCP, he
needs to know both ports and, more importantly, the current sequence
numbers. We rely on the unguessability of sequence numbers, only the
endpoints of a connection (and the few legitimate hops along the path
between them) know these secrets. Obviously, if an attack were able to
guess the secrets, he could attack your connections in a number of ways,
anyway.
So, try to think of a case where an attacker gains any advantage by
being able to pass a packet
  incoming from A to B on J
  outgoing from B to A on K
where he knows the connection secrets and couldn't just as well pass the
packet on I (where it would pass, anyway). I guess it would have to be
some very specific case where, for some reason, the attacker can only
inject packets on interfaces other than I.
I haven't seen a single example where this would matter in practice.
But, yes, if worry about this, make your state if-bound to I, and this
becomes a non-issue.
My guess is that we might eventually switch to if-bound as default. I'm
in favor of changing all examples in documentation to use it explicitely
until then. But if anyone is claiming that the default of floating
states leads to holes in rulesets of people unaware of the issue, I'd
like to see an practical example attack.
Daniel