In some email I received from ryan beasley, sie wrote: [...] > 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.
Another option is random deletion when it gets full but I really dislike that. [...] > 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 Yup. [...] > 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. I don't really like this idea because someone might fill it up with "immutable" things. 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 ? [...] > 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. ipf4.0 will also let you do something like that. You can define a pool of addresses that either form the address to match for that rule or as a means to lookup another rule. Darren
