I was just thinking the same thing, that strictly going by file name would not be best.
John T eServices For You > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- > [EMAIL PROTECTED] On Behalf Of Colbeck, Andrew > Sent: Thursday, November 17, 2005 10:04 AM > To: [email protected] > Subject: RE: [Declude.JunkMail] OT: another SOBERing though > > 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. --- 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.
