Marc Slemko <[EMAIL PROTECTED]> writes:
> On Mon, 12 Apr 1999, Timothy L. Mayo wrote:
>
> > If you cannot limit the number of connections you will accept to
> > something your system can handle, you need to re-think your setup.
>
> Erm... you just described a classic DoS attack. You put a limit of
> x connections in. One remote system uses all or nearly all of them.
> No one else can connect.
Erm... DoS may be a sensitive subject on this list! :-)
I think DJB has given a mathematically rigorous proof that "program
which is vulnerable to DoS" is one definition of "server". When a
server is serving all it can, it will refuse to serve any more. QED
The upshot is that _preventing_ a DoS is not at all possible. Any
rate-limiting, or other countermeasures you adopt, merely adjusts the
parameters within which a DoS must be conducted.
Limiting concurrency, ulimits, etc., are not about _preventing_ DoS,
which is impossible, but about ensuring that even under maxed-out
conditions the mail server will not die or become unstable.
> ...the root problem is qmail's rudeness in this area.
You may have a point here. Is there a well-defined rubric within which
we can assert, "It is ill-mannered to consume all available
connections to a remote server, just because those services are
needed?" Could be, I suppose--that's a question for admins.
Given that all service requests were legitimate, I would not mind my
server being pegged with connections from one host. When such
conditions become routine, from particular hosts, taking appropriate
action is why Sys Admins get paid. Of course, that's just MHO.
Len.
--
103. In Company of your Betters be not longer in eating than they are
lay not your Arm but only your hand upon the table.
-- George Washington, "Rules of Civility & Decent Behaviour"
