Thanks, Darrell. FYI, Trend Micro has a similar "outbreak manager" for Corporate desktop deployments, and a weak notification for their Exchange-integrated ScanMail. I use both and am not impressed.
Regarding your upcoming app, if you're aiming at catching viral outbreaks, can I suggest that you either calculate the byte size of the attachment(s), or go the distance to extract the MIME attachments, do an MD5 hash on them, and *not* compare the filename? The viruses nowadays make it de rigeur to send out multiple different text bodies and a varying attachment name, but rarely polymorph the attachment itself. You could certainly track all the names per unique MD5 hash (or file size). Andrew 8) > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Darrell ([EMAIL PROTECTED]) > Sent: Thursday, November 17, 2005 9:46 AM > To: [email protected] > Subject: Re: [Declude.JunkMail] OT: another SOBERing though > > Products do exist that can sense when users get infected and > start sending out massive amounts of mail - one that comes to > mind is McAfee's outbreak manager. We used that a while back > with good sucess under groupshield for an exchange > environment. Although it operated in a similar fashion as > Hijack does. > > One of the other things I felt were lacking is mechanisims to > stop propogation of viruses before the AV vendors have dats. > I am putting the finishing touches on a program that monitors > incoming/outgoing files and if (via thresholds) detects a > certain file being sent say x amoutn of time in x minutes it > will ban it. > > Darrell > > Colbeck, Andrew writes: > > > Yessir. > > > > Limiting the number of logons over an interval would be good. So > > would limiting the number of messages or recipients over an > interval, > > as Matt correctly pointed out. > > > > Deriving passwords by brute force attempts has always been > out there, > > but an automated fashion for collecting the usernames and > passwords is > > new. I assumed the same thing that Sandy pointed out, > which is that > > SOBER is going after the low-hanging fruit, and presumably > reads the > > mail server name and port while it's collecting the username and > > password. I would also assume that SOBER turns the mail > server name > > into a FQDN given the predilection for ISPs to call their > mail hosts > > "mail" or "smtp" or "pop" and provide the DNS search suffix in the > > DHCP lease. > > > > What I do find surprising is how few email packages aimed at ISPs > > support the security features we've been talking about here > to detect > > the bad guys in house. Declude Hijack is a notable exception. > > > > Corporations are in the same fix, as both are left with > "roll your own" > > solutions based on log file analysis. > > > > What that means in the real world is that they govern by exception; > > they don't have a security team at all, or they follow up > on incidents > > that are reported to them by an external body, e.g. "My > users aren't > > getting your mail anymore because your mail server is listed in > > SpamCop, CBL and SORBS". > > > > The spammers and malware writers will continue to find ways > to use the > > resources of other people. Once you've got a sensibly configured > > relay, secure mailer scripts on your website, users with reasonably > > secure passwords, SPF records, users using SMTP AUTH, > you've taken the > > easy stuff away from the bad guys. > > > > But you still have to expect that they'll abuse something > else, so you > > still need to put in limits where you can, and monitor your > logs for > > abuse. > > > > If you're interested, check out this paper from July 2004 entitled > > "Stopping Spam by Extrusion Detection" from: > > > > http://www.cl.cam.ac.uk/~rnc1/ > > > > And if you have any ideas or updated information, please share. > > > > Andrew 8) > > > > p.s. Sorry for the shot yesterday Matt, but when I see fish in a > > barrel, I just can't help myself. > > > > > > > > > > _____ > > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Darin Cox > > Sent: Thursday, November 17, 2005 5:42 AM > > To: [email protected] > > Subject: Re: [Declude.JunkMail] OT: another SOBERing though > > > > > > Another excellent point... limiting logon attempts. > > > > This reminds me of a discussion a while back that also > talked about > > limiting POP3 connections from a single users to every x minutes to > > reduce load. > > > > Darin. > > > > > > ----- Original Message ----- > > From: Markus Gufler <mailto:[EMAIL PROTECTED]> > > To: [email protected] > > Sent: Thursday, November 17, 2005 2:34 AM > > Subject: RE: [Declude.JunkMail] OT: another SOBERing though > > > > As I can understand a feature like "max. logon try's between x > > minutes" on the server would not prevent such hacking > attempts because > > they try to hack the login on a infected client. > > > > Question: How will this work? Are passwords still so > easy to read as > > 10 years ago in Win95 or will the malware listen the IP-traffic and > > read out the clear-text SMTP-Auth or POP3-Password? > > > > Next Question: Does have someone here some or numerous > cases where a > > client behind your Declude-Wall has become a infected sender? In my > > case here we have thousands of connecting clients but > nearly none of > > them are "in house" So I can't say it's not the case, but with my > > current knowledge I know only a hand full of cases where a > connecting > > client was infected. Most of them because they are > connecting also to > > another unprotected Mailbox. > > > > Markus > > > > > > > > > > _____ > > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Darin Cox > > Sent: Thursday, November 17, 2005 2:25 AM > > To: [email protected] > > Subject: Re: [Declude.JunkMail] OT: another > SOBERing though > > > > > > So the upshot of this is we need to > > > > 1. Figure out a way to enforce strong passwords > for mail users > > > > and > > > > 2. Monitor traffic for individual user accounts > on an intra-day > > basis, perhaps even have a means of detecting sharp increases in > > traffic from a particular account and alerting an admin to > > investigate. We do review a daily report the following morning of > > traffic by domain, but don't have anything in place to monitor by > > account, or to alert on an intra-day basis. > > > > Something to look into... > > > > Darin. > > > > > > ----- Original Message ----- > > From: Matt <mailto:[EMAIL PROTECTED]> > > To: [email protected] > > Sent: Wednesday, November 16, 2005 6:18 PM > > Subject: Re: [Declude.JunkMail] OT: another > SOBERing though > > > > Hmm, who would have thunk? > > > > > > > > Subject: Re: [Declude.JunkMail] SPF Success > > Date 12/24/2004 9:24 AM > > > > > http://www.mail-archive.com/[email protected]/msg22584.html > > IMO, the best way to stop forging is to > stop zombie spammers. The > > way to do this is FIRST implement port 587 as AUTH-only, and then > > widely block port 25. This means that mail clients would > exclusively > > use AUTH on private networks and connect to their mail > server on port > > 587 where only AUTHed connections would be allowed. Then > only servers > > would share non-AUTH E-mail on port 25. The only reason > why blocking > > port 25 is not very common currently is because it is severely > > limiting to customers and would cause support issues for > the ISP. If > > you first did the migration to port 587 AUTH-only > connections, which > > would take several years to accomplish in good order, ISP's > could move > > forward with port 25 blocking and cause many fewer issues as far as > > support and their clients were concerned. > > > > Basically what I am saying is that > forging isn't the issue, it's > > spam zombies, and to go after it as a forging issue is to miss the > > point. The big caveat here is that spammers will turn to > hacking AUTH > > in much larger numbers, and E-mail server software should > also widely > > implement a 'hijack' detection mechanism in order to help stem the > > abuse. I have already noted much more hacking going on, first with > > Earthlink's properties, and now with Prodigy as well. I > have little > > faith that these things will happen in the proper order or with the > > expedience necessary unfortunately, especially because of what I > > consider to be a distraction focused on forging coming from > the likes > > of SPF, Microsoft and Yahoo. I feel that the big players > are missing > > the point, and they are the ones that heavily influence > E-mail client > > and server software which is where the changes first need > to be implemented. > > > > > > Subject: Re: [Declude.JunkMail] > Question on SPF Setup. Was under > > You **May** etc **May** etc > > Date 6/30/2004 12:33 PM > > > > > http://www.mail-archive.com/[email protected]/msg19684.html > > What I do think would work much better > in the near term would be > > for every mail server to support and require SMTP AUTH through port > > 587 as proposed, and then have every ISP out there block > port 25 which > > would be used exclusively for non-AUTH'ed E-mail between systems. > > That would cut the zombie problem down dramatically without > > interrupting service, but this will probably take 5 years > or more to > > widely implement. I think this would have a much larger > effect than > > SPF in terms of blocking forging E-mail, the majority of > which comes > > from PC's attached to these residential ISP's presently. AUTH > > hacking, or even server hacking however will become much more > > predominant when the bar is raised in this manner, but > there should be > > many fewer machines to track. > > > > > > > > While this is certainly a bit of me patting > myself on my back, it is > > also a reminder to all that the worst is yet to come and > for the most > > part people are totally unprepared for this sort of thing. > So what's > > next? Maybe Geocities spam sent through hacked Yahoo accounts??? > > Oh wait, that's already happening. > > > > Matt > > > > > > > > > > Colbeck, Andrew wrote: > > > > So, we've seen the recent SOBER > variants used their own SMTP engine > > to > > propagate as well as a predefined list > of usernames and passwords > > at > > ISPs to send themselves. > > > > We've also seen that keeping viruses > and spam out of our mailboxes > > is > > easier when we can identify the sender > as a zombie, and that it is > > harder when the junk is coming from a > valid ISP and/or user at an > > ISP. > > > > > > http://www.viruslist.com/en/weblog?done=vlpolls_resp155596558 > > > > Well, Kaspersky is reporting that the > latest SOBER is also stealing > > (at > > least) Outlook usernames and passwords > from infectees. > > > > Therefore, we can reasonably expect > more junk coming from AUTH'ed > > senders. > > > > > > Andrew. > > > > > > > > --- > > This E-mail came from the > Declude.JunkMail mailing list. To > > unsubscribe, just send an E-mail to > [EMAIL PROTECTED], and > > type "unsubscribe Declude.JunkMail". > The archives can be found > > at http://www.mail-archive.com. > > > > > > > > > > > > > -------------------------------------------------------------- > ---------- > Check out http://www.invariantsystems.com for utilities for > Declude And > Imail. IMail/Declude Overflow Queue Monitoring, SURBL/URI > integration, MRTG > Integration, and Log Parsers. > > > --- > This E-mail came from the Declude.JunkMail mailing list. To > unsubscribe, just send an E-mail to [EMAIL PROTECTED], and > type "unsubscribe Declude.JunkMail". The archives can be found > at http://www.mail-archive.com. > --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
