Drastic milter errors
David F. Skoll
Jose Marcio Martins da Cruz (Jose-Marc...@ensmp.fr) wrote:
> Claus answer is right. libmilter checks if there is no more file
> descriptors available and exits after some number of errors.
Really?? I can't believe that! libmilter should *NEVER* exit because of
resource exhaustion.
> IMHO, it's up to the application to control system resources not to the
> library.
> But that's not the problem. As long your system has bounded resources
> (and your system continues to be bounded if you change the value of this
> constant), your system is allways vulnerable to a DoS.
Very true. MIMEDefang normally puts a hard limit on the number of
concurrent busy slaves, so normally you will never run out of file
descriptors -- MIMEDefang will start tempfailing mail before this
happens. But while most MD installations set the limit at tens or a
couple of hundred slaves, the person I was referring to set it at a
thousand, and he hit the file-descriptor limit.
> Robust filters shall measure available resources and take measures when
> used resources are near the bound.
Again, I disagree. This should be the operating system's job. Trying
to be too clever can simply result in your server performing sub-optimally.
It's very difficult to distinguish between legitimate heavy load
and a DDoS attack. Often, it's best just to let your server work through
the jam.
Setting MaxDaemonChildren is almost never a good idea; that makes a DoS
attack trivial with virtually no CPU cost to the attacker. Setting a limit
on the number of busy slaves (as MIMEDefang does) also opens you up to
DoS attacks, but the attacker actually has to work hard at it, and you
notice it pretty quickly in your mail logs.
The most useful Sendmail parameter for limiting DoS attacks is
ConnectionRateThrottle.
> Otherwise, this constant defines the dimension of type fd_set array. The
> greater the dimension is, the less efficient select function call is.
When you're running hundreds of concurrent Perl scanners, the inefficiency
of select() isn't a big part of the picture. :-) Each Perl process takes
50-200ms to scan the message, so adding a few microseconds on select()
doesn't matter.
--
David.
Claus Aßmann
> Jose Marcio Martins da Cruz (Jose-Marc...@ensmp.fr) wrote:
> > Claus answer is right. libmilter checks if there is no more file
> > descriptors available and exits after some number of errors.
> Really?? I can't believe that! libmilter should *NEVER* exit because of
> resource exhaustion.
What do you suggest to do if the same error occurs over and over
again? After some time you have to give up...
See for example libmilter/listen.c
int mcnt = 0; /* error count for malloc() failures */
int tcnt = 0; /* error count for thread_create() failures */
int acnt = 0; /* error count for accept() failures */
int scnt = 0; /* error count for select() failures */
David F. Skoll
> What do you suggest to do if the same error occurs over and over
> again? After some time you have to give up...
It depends. I agree that it's probably worth giving up after some number
of malloc failures, but I don't think you need to give up after the other
failures. Also, it depends on exactly why the functions fail; a failure
that returns EAGAIN or ENOMEM should be treated differently from one
that returns EINVAL or EBADF. The former are likely transient; the latter
are not.
--
David.