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>
|
- Re: softlabs, (continued)
- Re: softlabs, Robert Allerstorfer
- Re: softlabs, Professional Software Engineering
- Re: softlabs, Robert Allerstorfer
- Re: softlabs, Professional Software Engineering
- Re: softlabs, Robert Allerstorfer
- Re: softlabs,
Bob George <=
- Re: softlabs, Robert Allerstorfer
- Re: softlabs, Ruud H.G. van Tol
- Re: softlabs, Professional Software Engineering
- Re: softlabs, Professional Software Engineering
- Re: softlabs, Nikos K. Kantarakias
- Re: softlabs, Robert Allerstorfer
- Re: softlabs, Professional Software Engineering
- Re: softlabs, Robert Allerstorfer
|
|
|