Andy Fiddaman wrote:
Having a maximum at all makes it easy for someone to DoS you because aYou dont have a max process/children configuration for sendmail? That enables the same thing.
thread is created for each new SMTP connection.. just connect X times and
don't start entering a sender address.
Besides with all the cheap zombies out there, they can just flood you with viruses all at once. Cost the same to the attacker.
I think the thread maximum should be implemented around the actual virusMemory, threads, file descriptors.
scan because having a thread which is just waiting to receive an email
doesn't actually impact on system resources significantly.
Delaying Sendmail's handling of email Is NOT a good idea. Sendmail has its own controls to handle max process and connection rate.
If you are not going to have the allowable resources to process, you bail.
How about implementing this as a semaphore in the eom callback, i.e.Yes but waiting around will cause sendmail processes to pile up, producing the DoS effect anyways (perhaps even worse). You are also delaying all other milters on the system.
decrement semaphore; scan using clamd increment semaphore;
That would limit the number of simultaneous scans and keep the
synchronisation completely within the eom() callback, so fixing the
problem with some threads exiting without decrementing the current
counter.
When the system stops accepting email because its being flooded, the sysadmin will come and block the attackers out, restoring service. As opposed to driving down to the datacenter to restore the thrashed box.
So long as clamfi_free is called it should always decrement. Clamfi_cleanup will always call clamfi_free if smfi_getprivdata(ctx) != NULL
That means that after we have successfuly stored privdata we should only be concerned about early thread termination.
libmilter will warn in syslog if the milter finishes with the private data pointer not null.
It also makes it difficult to mount a DoS attack because the clamd scanIt is impossible to protect from a DoS attack Your system just will never be big enough to take on the world, should it come knocking.Whats important is making sure that when the server is hit, the box is still usuable.
should return within a determinable amount of time.
In other words, the attacked services should fail/stop accepting work much sooner than the threshold of the box maxing out.
What you want to avoid are the trivial attacks that produce fake DoS. So set your max-children high enough to avoid that, taking into account your sendmail settings.
As always, any thoughts appreciated.
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Clamav-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/clamav-users
