[sniffer] Re: I got a strong attack today
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]
[sniffer] Re: I got a strong attack today
3) then be able to create a temporary rule to help block messages - must be viable until SNF has an updated ruleset to start clearing out the attack - I don't think declude (what I use w/SNF) has rule expirations (but would be a nice feature) What I do when I create a temp rule is to call it T_date_A and then B and then C and so forth. I then keep a rule_readme.txt file in the spool\declude directory that I update. John T # 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]
[sniffer] Re: I got a strong attack today
Hi I got a tool to test all messages in a folder with SNF. All with a non zero result is moved to a spam folder. Its like 84 lines of delphi code. If Pete will host the files I will supply the tool for free including source. 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] -- Mvh. Frank Jensen [EMAIL PROTECTED] www.pi.dk Imponerende, fascinerende og kæmpe Plakater f.eks. 149 x 149 = 629 kr Vi kan også lave plakat fra dit digitale foto www.plakatkunst.dk # This message is sent to you because you are subscribed to the mailing list sniffer@sortmonster.com. To unsubscribe, E-mail to: [EMAIL PROTECTED]
[sniffer] Re: I got a strong attack today
Hello Paul, A relatively easy and reliable way to recognize one of these storms is whenever your new SNF engine starts throwing Bs and Cs- That is - you can check the second.stat or minute.stat file for Black and Caution hits: rates c .. m b .. m /rates On most systems Caution and Black events are relatively rare, but during a storm these numbers tend to be high. It is conceivable that you could detect these conditions by checking the stat files and adjust your system's settings during a storm. _M Friday, January 4, 2008, 5:38:38 PM, you wrote: We saw the same thing this morning between 7:00 AM (GMT-0500) and about 8:30 AM. Big chunks were getting through (spam detection rate dropped to about 65-70% (from its normal 97-99%). Sniffer updates seemed to start quelling the attack after about an hour of getting pummeled. Because of the relatively short lifespan of these types of attacks you need to: 1) be aware of attack quickly - e.g. w/in 10-15 mins of seeing average detection rates drop below a certain threshold (maybe 85%?)) and 2) be able to determine if there is an easy way to ID the leaked messages (common source IP(s), From domains (SPF check would help), subject lines, etc) 3) then be able to create a temporary rule to help block messages - must be viable until SNF has an updated ruleset to start clearing out the attack - I don't think declude (what I use w/SNF) has rule expirations (but would be a nice feature) Paul --- -Original Message- From: Message Sniffer Community [mailto:[EMAIL PROTECTED] On Behalf Of Alberto Santoni Sent: Friday, January 04, 2008 4:56 PM To: Message Sniffer Community Subject: [sniffer] I got a strong attack today 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!! 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? 2) How can I reduce or block(!) this kind of attacks? With my best regards Alberto # 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 sniffer- [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED] # 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] -- 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]
[sniffer] Re: I got a strong attack today
Hello Alberto, Friday, January 4, 2008, 6:50:55 PM, you wrote: Pete Thank you very much for your very exhaustive response! It's what we do. ;-) Do you have any other information on this technology called Gauntlet that seems me very very interesting. There really isn't much more to it than what's been said. The concept has been around for several years now -- the details are platform and policy specific. We have it on the drawing board to include it as a feature in some platforms that we support - however that is a complicated piece of engineering since each platform is different and we support _MANY_ platforms. (sideline = put messages through the gauntlet) Consider just a few, for example: MDaemon calls SNF as a plugin and doesn't provide any simple (fool proof) method for message re-injection. Also, it is not clear that there is a friendly and reliable way to sideline the messages on this platform. We could sideline messages in IMail by parking the Q and D files in a special directory and then later re-processing them through SNF back to the spool... -- But, if Declude is present then we might instead wish to re-process the messages through the proc folder, and there are uncertainties about when and how to do this and how to pace it. -- If mxGuard is in place -- how would we re-process the messages at all? -- How could we ensure that virus scanning etc would be enabled (or not if desired?) SmarterMail could be handled (presumably) in a similar way to IMail except that the file structures are different as are a few assumptions about message processing and acceptable loads, etc. In Postfix systems we would need to create our own data structures to capture envelope information before we sidelined the message -- all that in addition to considerations of other processes that might be in place (without notice) and might need to be considered when we re-process the messages. Communigate systems store routing information in the message file itself which would simplify sidelining the messages but complicates the re-processing task - and again there are other processes that might be in place unannounced... All that by way of illustrating that the concept of Gauntlet is powerful and simple to understand, but not so simple to implement. For now we've been describing it to folks and helping them implement versions of Gauntlet in their proprietary systems. With a bit of luck and elbow grease we will hopefully release utilities and/or special versions of SNF to support this on some platforms -- This is particularly attractive since the GBUdb engine produces signals that theoretically allow us to activate and deactivate (or desensitize) Gauntlet under specific conditions very accurately. Specifically, GBUdb can provide a clear signal for the presence of a spam storm by monitoring Black and Caution activity. GBUdb also provides ready statistics on IPs so that we can define which IPs not to sideline (when the IP is reasonably well known and reasonably unlikely to send spam). -- That's about all I can think of to say about it at this time (at least without some more specific questions). But I don't think that Mxguard can manage all of this you are explaining in the message. That's probably true -- but not certain. Consider, for example, that your re-injection script could act just like IMail... * Drop the D file back into the spool * Drop the Q file back into the spool * IMMEDIATELY call mxGuard with the Q file in precisely the same way IMail does. In theory this would work for mxGuard or Declude since both programs would see this activity no differently than if IMail had just dropped a new message in for processing. That's a very big In theory -- because I've not tried it, but based on the available documentation the theory is sound. I will try to write a CDM to solve my queue problems Please keep us posted. Thanks, _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]
