On Sat, Dec 14, 2002 at 03:26:50AM +1100, Darren Reed wrote: > Another option is random deletion when it gets full but I really dislike > that.
I can see why. :).
*snip*
>> [ ... junk about immutable flag ... ]
>
> I don't really like this idea because someone might fill it up with
> "immutable" things.
>
Hm, yeah, someone else said the same thing. It isn't that good an idea,
but when I first thought of it, I imagined it only used to allow logins
from a certain host post 3WH. The worst I imagined that could happen
wouldn't have been worse than what's possible now.
> ipf4.0 will allow per-rule limits on the number of state sessions a
> rule may be responsible for.
>
> does that solve the problem well enough ?
I think that's a step in the right direction, but I'm not entirely sure
it's a complete solution.
For the sake of example, we'll use the default state entry limit of
4013. We're also using a single rules like the following for each
public service:
pass in quick proto tcp from any to <dstip> port = <dstport> flags S
keep state
For a single service, we could set an artificial limit on that rule to
maybe 4000 state entries. The states-per-rule feature could work here,
but it doesn't scale too well. Rather than having a pool of state
entries that's spread across every service as they're needed, each
service is now limited to at most (IPSTATE_MAX / <amount of services>) - 1
entries to leave room for management connections.
I guess it comes down to first determining how serious a problem this
really is. :).
We know that resource exhaustion is always going to be a problem. If
you can't bump the state table size because you're running out of
physical memory, it's either time to buy more or transition to more /
larger machines.
However, one doesn't spend money just to handle artificial load
introduced by attacks. (Well, those w/ tight or sensible budgets,
that is. ;). )
So the problem here, at least as I see it, is not being able to
respond to such attacks. As is now, there's nothing to stop someone
from using a pair of stateless rules, though there are a few _minor_
problems:
say we have something like
pass in quick proto tcp from <bastion> to <tgt> port = 22
pass out quick proto tcp from <tgt> port = 22 to <bastion>
tgt is now free to peg the upstream in RSTs. Worse yet, if <bastion>
has a significantly smaller pipe than <tgt> and the filter host, a 3rd
party ends up indirectly DoSing the bastion with responses from <tgt>.
If this is big enough of a problem that someone should want to avoid
a pair of stateless rules, then how about the following :
In addition to the state table limit defined by IPSTATE_MAX, rig up
an artificial limit that's IPSTATE_MAX - <x> entries large. (This is
similar to operating systems that reserve <x> processes for
exclusive use by the superuser.) When this artificial limit is hit,
then only special connections can consume the rest of table space.
Example conditions include matching an "auth" rule, or matching a
rule with a yet-to-be-defined identifier (like priv? ;). )
e.g., pass in quick proto tcp from <bastion> to <tgt> port = 22
flags S keep state priv
The work to do this would require only a few small changes to
ipf.5, ip_state.c (fr_addstate), and if there's to be a new keyword
and flag, ipf_y.y and ip_state.h.
Soo ... any of this seem worthwhile? If so, I can whip up the patches
against 4.0.
--
ryan beasley <[EMAIL PROTECTED]>
GPG ID: 0x16EFBD48 http://www.goddamnbastard.org
msg01980/pgp00000.pgp
Description: PGP signature
