Ian FREISLICH <ianf@???> (Mi 12 Mär 2008 14:16:43 CET):
> Matt wrote:
> > > > delay = 10s
> > >
> > > Very bad idea to add delays if you are suffering from too many concurrent
> > > connections!
> >
> > You could defer instead.
>
> Except that I've seen reports of zombie armies reconnecting at very
> high rates when their connections are dropped. And defering on
> connect doesn't give you the connection slot back until the remote
> end disconnects, the connection times out or you drop it.
If you've linux, you might test using the TARPIT target, combined with
the hashlimit (keyed by srcip).
I'm not sure, if such tarpit feature could be implemented in an
userspace application, since I suspect that there's kernel support
neccessary.
From the iptables man page:
TARPIT
Captures and holds incoming TCP connections using no local per-connec‐
tion resources. Connections are accepted, but immediately switched to
the persist state (0 byte window), in which the remote side stops send‐
ing data and asks to continue every 60-240 seconds. Attempts to close
the connection are ignored, forcing the remote side to time out the
connection in 12-24 minutes.
--
Heiko
