On Wed, Dec 04, 2002 at 01:02:53PM -0800, Phil Dibowitz wrote: > This won't solve your problem, but you'll have a much more effecient > ruleset with this:
[ rules with 'keep state' snipped ]
> Advantages:
> - less rules
> - more secure, it follows the state
> - will allow any related ICMPs such as type 3/4 needed for Path MTU
> Discovery
Disadvantage:
May lead to a particularly nasty situation in the cases of either heavy
load or DoS.
While this is probably common sense to the lot of you, it may be useful to
the original poster.
IP Filter has a finite amount of space defined at compile time to use for
state entries. If this limit is reached, either from heavy loads or
malice, IP Filter begins cycling through idle state entries, freeing them
as new entries are needed. Initially starting with entries idle for more
than 4 days, extreme circumstances may lead it to reclaim entries idle for
no less than 30 seconds.
This can be particularly ugly if your login (or any other) services are
governed by state rules:
e.g., pass in quick proto tcp from <trusted> to <fw> port = 22 flags S
keep state
One workaround involves using a pair of 'pass [in,out] quick' rules for
each critical service, like SSH from a trusted host. (Please, no comments
bashing SSH, suggesting console access, etc.) That'd at least permit
logins to either bump the state table size or start filtering 'bad'
traffic. As to avoid this problem altogether, you could skip stateful
rules completely (requiring applicable ICMP/PMTU-D rules, of course!).
However, besides losing the added comfort in passing strictly in-window
segments, rule management may become a bit more of a pain as you'd have to
deal with individual in/out rules.
Generally speaking, state table exhaustion is more of a concern to me than
the add'l effort put towards keeping pairs of rules in check. Also, as
small as my rulesets have been, the marginal time spent traversing the
filterset has proven so far insignificant.
When it comes to possible permanent workarounds for the situations above,
I thought of the following:
1) New state flag, IS_STATIC or IS_IMMUTABLE, in addition to add'l rule
option "immutable" (dependent on "keep state"). State entries created
by rules with the "immutable" option would have the IS_IMMUTABLE
flag set such that they are simply overlooked when IP Filter must
crunch to kill off "idle" state entries.
2) Lightweight state entries (whose merit is fairly dependent on my
assumption that large filterset lookups can significantly affect
performance compared to typical state table lookups). I'd
think of this as a way to bypass the bulk of filter processing.
These would behave as a hybrid of firewall rules and state entries:
Like a firewall rule entry, cost is paid once at load time.
Rather than having a tree of grouped rules, they're hashed by
transport protocol, destination address and port only. Lookups
would be somewhat similar to portions of fr_checkstate with
SI_W_SADDR|SI_W_SPORT flags set. Additionally, one would shed the
cost of verifying a TCP segment's presence within the current TCP
window.
(Anywho, I find the first to be much more plausible, and honestly, I
started losing focus thinking of / writing about the second while
becoming increasingly sleepy, though I still thought it worth sharing.
Apologies if these came up on the list before; didn't find anything
after a cursory Googling. :).)
Thoughts?
--
ryan beasley <[EMAIL PROTECTED]>
GPG ID: 0x16EFBD48 http://www.goddamnbastard.org
msg01897/pgp00000.pgp
Description: PGP signature
