procmail
[Top] [All Lists]

Re: softlabs

2004-03-04 12:31:42
Robert Allerstorfer wrote:

[...]
My tool does exactly what it is intended to do, nothing more and
nothing less, as stated in the ReadMe which is viewable at

http://www.softlabs.info/antivirus/SoftlabsAV/ReadMe.txt

It detects if a mail has an attachment containing a Windows Executable
that is most likely a virus, no matter if the "bad" Executable is
attached directly or packed within a ZIP attachment (which may also be
encrypted). Such mails will be marked by adding a "X-Virus-Filter"
header, stating that they have been found to likely be infected. [...]
Robert, I applaud your efforts at developing a useful tool for aiding with slowing/stopping the spread of infections. I think though that you may be taken to task -- and not unfairly -- for referring to it as "anti-virus", simply because, as I understand it, it does NOT detect viruses with any degree of certainty. It quarantines attachments meeting specific criteria. THIS IS NOT BAD, but I thing there's a very good chance that anybody reading that header might be given a false sense of security, in that:

1. A new and emerging threat that uses as-yet unseen file naming patterns would not be detected. (Yes, your tool can be updated, but you're then in the same reactive boat as the rest of the AV vendors.)

2. No specific alert is raised if a virus is actually in the file. A notice is given that "a virus-like" file was attached, but I would expect those would be ignored in short order in an organization where file attachments are used. An alarm that rings constantly is usually turned off.

3. It does not protect against a host of other threats commonly referred to as "virus", including document macros etc. Yes, I agree it's idiotic, but there will be users out there who will argue that "it was labelled as OK, so I opened it!"

There's also the problem of essentially "accusing" the sender of sending an infected file merely for sending a TYPE of attachment.... NOT good for business if you are dependent on customers sending "stuff". The point can be argued, but "anti-virus", as used today, commonly implies active heuristics and analysis of content independent of other file characteristics (or at least the ability to do such analysis). For liability reasons, I am NOT going to be comfortable using that term to describe a tool that filters a handful of file types. (I think we're approaching the point that this discussion belongs on a virus/security-centric list, or at least OFF this one. :)

Don't get me wrong: As I noted in my earlier "defense-in-depth" message, policy-based filtering/quarantine is an EXCELLENT tool. I use anomy sanitizer, mime-defang and other filtering/defanging/quaratine tools. But they provide filtering only, much like stateless ACLs on perimeter routers. It does what it does, does it quickly and effectively, but IS NOT a complete solution. It is however, COMPLIMENTARY to other measures. Such a filter works in those cases where "policy" dictates that certain types of attachments are not allowed. For that matter, a procmail rule to simply delete such content could be argued to be as effective. If your policy states "all [whatever] attachments will be summarily deleted, the problem's pretty simple.

I think your tool has potential. If an organization (even a poor one with a handful of users) needs to implement a policy of "no zip attachments until further notice", it's PERFECT. But I think there'a packaging issue with implying "anti-virus" capabilities.

Then, the infected mail will be moved to a Quarantine directory. In
addition, all viruses can be extracted and stored within a "viruses"
directory, to be able to scan them using an external Virus Scanner.
I think content that passes that 2nd level of test can be labelled "checked for virus" with a higher degree of confidence. At that point, it would make sense for ALL attachments to be put through the two-step process, with the implied 3rd step that the user must actually accept the file and vouch for it's authenticity. (Tempting to meander into policy regarding "user responsibiilty" but it goes here.)

For me, it has already isolated lots of viruses, and it did not let
any single infected mail through. All isolated files have in fact been
viruses, as scanning with another software showed.
When I shut down mail, no viruse get through. :) And yes, today all the messages with attachments were infected.

This is exactly my goal: filtering mails that most likely contain a
virus, *without* identifying them if they are in fact infected. So it
can be used as a permanent first layer protection, without the need of
providing virus definitions, which would be (1) a hassle, (2) never up
to date, and (3) an overhead. Scanning each and every mail for dozens
of known signatures may be useful during the first days a new virus
got wild, but is useless after a few days.

It's also not useful the on Day 0.

[...]
But, for people afraid to get mails isolated on a false-positive basis,
I have added the following machanism to the current version 0.3: If
EXTRACT_VIRUSES has been turned on, the VIRUSFILE variable always
holds the full path to found-to-be virus file, before quarantening the
mail.

This allows one to plug a third-party scanner before the mail would
usually be moved into the quarantene directory; and moving could be
prevented if the external scanner does not identify the "virus" file
as infected. Personally, I don't need this overhead, since I have a
zero false-positive rate and check the isolated viruses manually, from
time to time.
The "quarantine, scan then accept" multi-level check is good if applied to all attachments. Again though, I'm a lot more comfortable saying "checked for virus" after these steps.

- Bob


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>