On Sat, Jun 29, 2002 at 07:22:18PM +0200, Patrick Schaaf wrote: > I think my analysis shows a possible problem with your approach: when such > a port scan results in an overly long single bucket list, that list will > prevail for up to 5 days. If N is the number of buckets, and newly arriving > connections are evenly spread over the buckets, then every Nth connection > will fall into that overly long bucket - being blocked if we apply your > cutting logic unmodified. > > However, in my observation of those problematic buckets, the connections > are UNREPLIED. Then we can use the same trick that is used when > ip_conntrack_max is reached: recycle one of those UNREPLIED > connections immediately for the new conntrack.
this sounds like a sane way to go. > NO. They were "alone in their bucket". In other words, no active connection > fell into the same bucket, so they won't come into play at all during lookup. > And, as each entry has its individual timer, there is no scanning of the > overall table, so they would be really untouched in real life, until they > timeout after 5 days. but how high is the probability that they are [and remain] 'alone in their bucket' ? This could just be a coincidence... > At this point, I would like to stop for some time, and await results > from other's real world ip_conntrack setups. I'm going to do this on a couple of my firewalls on Jul 08 [that's the single day I'm going to be in .de between my different trips...]. Right now I only have dialup modem internet... So please wait another couple of days. Thanks. > best regards > Patrick -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ ============================================================================ GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)
