Re: [cobalt-security] Sendmail - (was: SHP flaw)

[Michael Stauber <cobalt@xxxxxxxxxxxxxx>]

> I kind of disagree, if someone generated that max. load, then other
> users would be denied access.
>
> While it isn't a huge thing, it can be abused to prevent traffic.

Correct. In admin training we once brought an Sun E10000 (pretty big iron) to 
its knees because those lines are by default commented out in Solaris' 
Sendmail configuration. 

I'd say that a load average of 15 and 20 respectively is enough to justify 
some proactive if not drastic actions. With Sendmail continuing to  send 
emails you'll otherwise risk that the entire server goes down, which will 
also have impact on all users. 

A temporary mailserver outage is certainly more acceptable than a crash of the 
whole box, but the choice is of course yours.

Let's focuss a little more on security while we're talking about Sendmail.

There are two other quite important switches in the sendmail.cf:

# maximum number of children we allow at one time
O MaxDaemonChildren=15

# maximum number of new connections per second
O ConnectionRateThrottle=3

The actual values in your config files might be different. 

The MaxDaemonChildren is pretty important, too, as it defines how many 
children processes Sendmail is allowed to fork. With that value as shown 
above up to 15 emails will be processed simulteanously. Doesn't sound like 
much, but for a RaQ3 that's already pretty close to meltdown if the webserver 
is pretty active and you have little memory to go around.

Comment that value out and you open yourself up for a DOS attack which will 
bring the server down to it's knees. Less than five lines of shell script 
will do the job - either locally or remotely.

If you have all four values set properly, then the DOS attack will only 
increase the servers load average up to the point where Sendmail shuts down. 
Without these measures in place Linux runs either out of file descriptors, 
out of memory or the load average will go straight through the roof.

-- 

With best regards,

Michael Stauber
mstauber@xxxxxxxxxxxxxx
Unix/Linux Support Engineer