Hello Alberto, Friday, January 4, 2008, 4:56:29 PM, you wrote:
> Hello > I got a strong attack today, over thousand messages at the same time!! > The usual technique: > Impersonate the victim and send to non valid users of one domain of > mine!! > Changing IP for each message.... UNBELIEVABLE!! This is very common these days. We call it getting caught in the light. Our spamtrap server is currently experiencing a similar "attack" and is seeing 1850+ messages per minute. Luckily we've killed this particular campaign a few hours ago so leakage is only 7/min and 890+/min of these messages are being truncated (scan stopped based on IP via GBUdb) > The only solution was, to stop all the services and move all the spool > files in a temp directory. > I won't use the "nobody" alias because at least the iMail Access Control > can stop some bad IPs. > My config is: > Imail 9.23 > Mxguard 3.1 > Message Sniffer > InvURIBL 3.7 > Two questions: > 1) There is a way or tool to recycle back good messages from the temp > directory into the queue? You should be able to write a cmd script to test the messages in your temp folder against SNF and place the clean messages back into the spool for delivery. This doesn't give you a complete solution, but it is reasonably viable in such cases. I've not heard of it, but you may be able to find or write a similar utility to put the temp messages through the entire scan process at some reasonable pace -- You might ask DG about that - I'm not sure what would be the best way to go about that w/ mxGuard and he may have a solution already or know where it's buried. Side Note: We actually have a technology that we've simulated and not deployed called Gauntlet. Under certain conditions messages are shunted to a waiting area where their scanning and delivery are delayed for a period of time so that filtering systems can "catch up"... For example, messages that arrive from completely unknown IPs would have to "run the gauntlet" before being delivered. The sensitivity of the shunting system could be guided by "storm data" (B and C counts) from GBUdb to reduce the possibility of delaying ordinary messages. What you are describing is a manual version of this process. > 2) How can I reduce or block(!) this kind of attacks? The new version of SNF is very good at reducing this kind of attack because the GBUdb component frequently can identify bad IP sources very quickly after a new campaign begins and is able to block many of the messages based on the IP reputation information known by the network. In some cases this might include substantially all of the attack prior to new pattern rules reaching your system -- in all cases at least some fraction of the attack would be identified (based on observations). The system will become more sensitive as more systems begin using the new software -- at this time it is remarkably sensitive even though only a small fraction of SNF users are already using it -- so we expect significant improvements. In this case, for example, many of the messages arriving would be seen by SNF, identified after a very short scan (only the first few hundred bytes), and then most-likely deleted (depending on how you tune your system; also I'm not sure what options are available from mxGuard w/ regard to preempting additional tests and/or test ordering). Given your system's configuration I don't know of any way to block this kind of attack without adding additional components. A couple that come to mind are SPF checking (so that any message pretending to come from your domains must actually be coming from your servers before being accepted), and graylisting which, while sometimes problematic, currently provides some pretty good protection against dumb-bot attacks. (Note that the newer bot softwares out there easily defy gray listing so it's effectiveness is dropping quickly) Hope this helps, Best, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. ############################################################# This message is sent to you because you are subscribed to the mailing list <sniffer@sortmonster.com>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
