Summary - Handling Spam Surges
Here is summary of all the responses. Thanks to all who resonded, your suggestions have been very helpful. We will - reduce the number of SA max-children - look at ratelimit in exim - only spam scan messages under a certain size Aaron Wolfe We reduce the messages bound for SA to less than 10% of our traffic by a combination of postfix UCE checks, a couple very accurate RBLs, selective greylisting and our own whitelist. When the surges/DOS happen, they tend to increase the number of messages thrown away but rarely effect the volume running through SA. Dave Funk With only 2GB of memory you could die in swapping hell with max-children=150. Each SA process will take 30~60Mbyes of RSS (depending upon addition of optional rules & plugins). This means that 150 children could take 5GB of ram, thus hitting your swap hard. Either add more RAM or reduce that max-children. To prevent melt-down from surges/DoS attacks some kind of incoming SMTP rate limiting is the way to go (with that small a setup). This would be done by your Exim config, ask the Exim list for suggestions on this. Michael Scheidell Handle it in the MTA. Best to block all unknown recipients at least. The rest of what to do in the MTA depends on what MTA you have. Once the MTA is finished with it then pass it to SA. If under attack, only thing you can do to help SA is disable network tests till its done. Visit the mailing list or FAQ's of the MTA you are using for more help on this. (example: smtp connection limiting, session tarpiting, even some firewall rules to limit concurrent connections might help) === Thanks Paul
RE: Handling Spam Surges
> -Original Message- > From: Paul Griffith [mailto:[EMAIL PROTECTED] > Sent: Monday, September 10, 2007 12:48 PM > To: users@spamassassin.apache.org > Subject: Handling Spam Surges > > > Greetings, > > How do you handle Spam surges/DoS attacks? We just had a Spam > surge/DoS > and are looking at ways to better withstand (as best as we > can) another > surge Handle it in the MTA. Best to block all unknown recipients at least. The rest of what to do in the MTA depends on what MTA you have. Once the MTA is finished with it then pass it to SA. If under attack, only thing you can do to help SA is disable network tests till its done. Visit the mailing list or FAQ's of the MTA you are using for more help on this. (example: smtp connection limiting, session tarpiting, even some firewall rules to limit concurrent connections might help) -- Michael Scheidell, CTO SECNAP Network Security Corporation Keep up to date with latest information on IT security: Real time security alerts: http://www.secnap.com/news _ This email has been scanned and certified safe by SpammerTrap(tm). For Information please see http://www.spammertrap.com _
Re: Handling Spam Surges
On Mon, 10 Sep 2007, Paul Griffith wrote:
> Greetings,
>
> How do you handle Spam surges/DoS attacks? We just had a Spam surge/DoS
> and are looking at ways to better withstand (as best as we can) another
> surge
>
>
> Here is how we start SA:
>
> -c -d -r $PIDFILE -s /var/log/spamd --socketpath=$SOCKET
> --max-children=150 --min-children=10
>
> Our (1) mail server is configured like this:
>
> CentOS 4.5
> Exim 4.67
> SpamAssassin version 3.2.3 running on Perl version 5.8.8
> ClamAV 0.91.2 (saneSecurity updates)
> - handles incoming/outgoing mail
> - handles imap/pop/webmail request
>
> Intel D Cpu 3.00Ghz with 2GB of Mem
> 80GB SATA root disk
> 200GB SATA mail disk (softraid mirror)
> 2xIntel e1000
With only 2GB of memory you could die in swapping hell with
max-children=150. Each SA process will take 30~60Mbyes of RSS
(depending upon addition of optional rules & plugins).
This means that 150 children could take 5GB of ram, thus hitting
your swap hard. Either add more RAM or reduce that max-children.
To prevent melt-down from surges/DoS attacks some kind of incoming
SMTP rate limiting is the way to go (with that small a setup).
This would be done by your Exim config, ask the Exim list for
suggestions on this.
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: Handling Spam Surges
_perl/5.8.8/Mail/SpamAssassin/SpamdForkScaling.pm line > 171. > Fri Sep 7 16:30:39 2007 [26914] warn: prefork: killed child 24702 > Fri Sep 7 16:30:41 2007 [26914] info: spamd: handled cleanup of child pid > 24702 due to SIGCHLD > Fri Sep 7 16:30:41 2007 [26914] warn: prefork: cannot ping 24687, file > handle not defined, child likely to still be processing SIGCHLD handler > after killing itself > Fri Sep 7 16:30:41 2007 [26914] warn: prefork: killing failed child 24687 > fd=undefined at > /xsys/lib/perl5/site_perl/5.8.8/Mail/SpamAssassin/SpamdForkScaling.pm line > 171. > Fri Sep 7 16:30:41 2007 [26914] warn: prefork: killed child 24687 > > > Looking at the swap usage, I was thinking I would be better if I reduced > the number of children processes and let thing queue up. I know I will > also have to look at exim and it's ratelimit command. Any other idea's on > handling spam surges/DoS? > > Thanks > Paul > At my site we operate under the presumption that SpamAssassin should be avoided if at all possible because it is so expensive on our resources compared to some other easy checks. This helps us to deal with DoS and "surges" from retarded bots quite well (so far at least). We reduce the messages bound for SA to less than 10% of our traffic by a combination of postfix UCE checks, a couple very accurate RBLs, selective greylisting and our own whitelist. When the surges/DOS happen, they tend to increase the number of messages thrown away but rarely effect the volume running through SA. -Aaron
Handling Spam Surges
/xsys/lib/perl5/site_perl/5.8.8/Mail/SpamAssassin/SpamdForkScaling.pm line 171. Fri Sep 7 16:30:41 2007 [26914] warn: prefork: killed child 24687 Looking at the swap usage, I was thinking I would be better if I reduced the number of children processes and let thing queue up. I know I will also have to look at exim and it's ratelimit command. Any other idea's on handling spam surges/DoS? Thanks Paul
