I'm not aware of any mail scanner that does this without running an external anti-virus or something alike, although is not that intensive to follow
zip headers (as they already do with the MIME headers in order to drop external attachments). Most scanners can accept an anti-virus plugin and them scan inside zip files, but that requires more processing power, more queue disk space, more RAM, more administration to update virus
the patterns,
and so on. The cost/benefit usually pays off, but more complexity means less people will adopt the solution, thus making worm spreading easier.
your description makes it all sound quite complicated, possibly because you are passing all the processing down to the end-user's machine.
I was talking about central anti-virus processing... although it's easier on administration than updating hundreds or thousands of machines, it establishes a central bottleneck. Doing decompression and extensive pattern matching on a high volume server is not an easy task.
we have anti-virus (clamav) and anti-spam (spamassassin) running at the server level, and thus save the end-user alot of cycles.
Even on low volume servers, this task is not something one would do without some thinking; on high volume, this is achievable but would require a good systems design to cope with the higher latency between mail receive and mail delivery.
clamav will look inside zip files, and automatically updates its signature database.
spamassassin uses both global rules and per-user rules to rate incoming email and reduce the impact of spam.
Been there at many installations of MailScanner (http://www.mailscanner.info).
we even run in-line scans of MIME headers during the SMTP process and reject specific attachments (.exe, .pif, etc) without even bothering the end-user.
That kind of filtering is much easier to configure, administer and goes low on resources. Extending this to verify filenames inside zip files would not be difficult to do, and is simple and not intensive enough to lots of people to turn such filters on. Rubens
so would a milter for sendmail that strips off attachments, queues them for decompression and scanning at a later time be more useful? Say such a milter could strip off attachments, replacing them with a URL in the email that will allow the recipient to download them if they prove clean. It's not an instant gratification, but it'll let you distribute the scanning among several machines. if an attachment gets denied, the url would inform the user why they can't access the file. i had an idea to write this a while ago, but never felt like writing the mime code to handle strange attachments. mike On Mon, 1 Mar 2004, Rubens Kuhl Jr. wrote:
I'm not aware of any mail scanner that does this without running an external anti-virus or something alike, although is not that intensive to follow the zip headers (as they already do with the MIME headers in order to drop external attachments). Most scanners can accept an anti-virus plugin and them scan inside zip files, but that requires more processing power, more queue disk space, more RAM, more administration to update virus patterns, and so on. The cost/benefit usually pays off, but more complexity means less people will adopt the solution, thus making worm spreading easier.
your description makes it all sound quite complicated, possibly because you are passing all the processing down to the end-user's machine.
I was talking about central anti-virus processing... although it's easier on administration than updating hundreds or thousands of machines, it establishes a central bottleneck. Doing decompression and extensive pattern matching on a high volume server is not an easy task.
we have anti-virus (clamav) and anti-spam (spamassassin) running at the server level, and thus save the end-user alot of cycles.
Even on low volume servers, this task is not something one would do without some thinking; on high volume, this is achievable but would require a good systems design to cope with the higher latency between mail receive and mail delivery.
clamav will look inside zip files, and automatically updates its signature database.
spamassassin uses both global rules and per-user rules to rate incoming email and reduce the impact of spam.
Been there at many installations of MailScanner (http://www.mailscanner.info).
we even run in-line scans of MIME headers during the SMTP process and reject specific attachments (.exe, .pif, etc) without even bothering the end-user.
That kind of filtering is much easier to configure, administer and goes low on resources. Extending this to verify filenames inside zip files would not be difficult to do, and is simple and not intensive enough to lots of people to turn such filters on.
Rubens
!DSPAM:4042cb6d168642834354387!
Say such a milter could strip off attachments, replacing them with a URL in the email that will allow the recipient to download them if they prove clean. It's not an instant gratification, but it'll let you distribute the scanning
About 5-6 yrs ago I wrote a system for a customer that would look at attachments, and for any attachment not of a whitelisted type (I might have checked against /etc/magic to prevent bogus extensions), it would do just that. The file got removed from the email and replaced with a note. The attachment got dumped into a DB and the admins would validate it by hand via a web-based interface (this was the customer spec). All zip files got popped open and the contents checked. If the admins approved the attachment, I think it got re-mailed to the end-user. The system worked well. It had the high manual overhead, but that's what they wanted. There's no reason to not do the same and just queue for virus scanning if the mail server needs the load lightened. Steve ---- Steve Birnbaum SkyVision Global Networks Phone: +44 20 83871750 Email: steve.birnbaum@sky-vision.net Experience is something you don't get until just after you need it.
I just received 2 copies of Bagle.F, embedded inside a password-protected zip file. Comes right through a full virus scan undetected. ------------------------------------------- Sent: Sunday, February 29, 2004 7:04 PM Subject: Bad girl I am from Taiwan but I study in Camden, New Jersey now. I like to know people from different places . password for archive: 87326
Yup, got this one too .. according to nai.com theres a whole bunch of these variants up to bagle.g .. there is also a netsky.d out today as well pity nai.com arent updating their dat files as fast as their website :( Steve On Mon, 1 Mar 2004, Mike Nice wrote:
I just received 2 copies of Bagle.F, embedded inside a password-protected zip file. Comes right through a full virus scan undetected.
------------------------------------------- Sent: Sunday, February 29, 2004 7:04 PM Subject: Bad girl
I am from Taiwan but I study in Camden, New Jersey now. I like to know people from different places . password for archive: 87326
** Reply to message from "Mike Nice" <niceman@att.net> on Mon, 1 Mar 2004 07:23:07 -0500
I just received 2 copies of Bagle.F, embedded inside a password-protected zip file. Comes right through a full virus scan undetected.
------------------------------------------- Sent: Sunday, February 29, 2004 7:04 PM Subject: Bad girl
I am from Taiwan but I study in Camden, New Jersey now. I like to know people from different places . password for archive: 87326
Okay, from an operational standpoint, who really wants a customer who would open this as a customer in the first place? It seems like it takes some seriously stubborn stupidity to do so. <slightly sarcastic suggstion follows> I'm beginning to think that we should start charging like insurance companies do... the more dumb things you do on the network, like opening stuff like this and spreading viruses, the more we get to charge you. Of course we'd have to have someone maintain a central database of customers that have suffered "accidents" like this so they couldn't benefit from switching ISPs... too many offenses and you pay -a lot- for your internet access on a tightly firewalled ISP where you can only access stuff by proxy servers - I'm sure you all get the idea. There are of course a million different reasons this won't work, but it is a nice dream, eh? -- Jeff Shultz Loose nut behind the wheel.
Jeff Shultz wrote:
Okay, from an operational standpoint, who really wants a customer who would open this as a customer in the first place? It seems like it takes some seriously stubborn stupidity to do so.
<slightly sarcastic suggstion follows>
I'm beginning to think that we should start charging like insurance companies do... the more dumb things you do on the network, like opening stuff like this and spreading viruses, the more we get to charge you.
Of course we'd have to have someone maintain a central database of customers that have suffered "accidents" like this so they couldn't benefit from switching ISPs... too many offenses and you pay -a lot- for your internet access on a tightly firewalled ISP where you can only access stuff by proxy servers - I'm sure you all get the idea.
There are of course a million different reasons this won't work, but it is a nice dream, eh?
One of the reasons might be in the legal system extant in some parts of the world. I don't agree that what follows is a good idea, but I am not a lawyer and I am not current in any of the relevant regulations. I am told that there are legally enforceable obligations to account for things like complaints, resume submissions, job applications, some requests for information, and so on.
participants (7)
-
Jeff Shultz -
Laurence F. Sheldon, Jr. -
Michael Wiacek -
Mike Nice -
Rubens Kuhl Jr. -
Stephen J. Wilcox -
Steve Birnbaum