Hello Pi-Web, Absolutely. We like community developed tools :-)
Zip up the tool, source, readme et al and send it to support@ attached to an email. Put the description you would like to see in the text of your email. We'll add it to our site. Thanks! _M Friday, January 4, 2008, 5:28:46 PM, you wrote: > 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 <[email protected]>. >> 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 <[email protected]>. 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]>
