dennispe at inetnw
May 20, 2009, 9:22 AM
Post #5 of 9
(1198 views)
Permalink
|
Bill Landry wrote:
>
> So, the problem with checking to see if the .ign entry still resides in
> the database file or not has a flaw. As a signature writer, if I have a
> signature that, for example is called:
>
> Spam.Email.123:25:26f757073
>
> and someone reports this as a false positive and I either modify the
> signature (meaning it's still there and the script finds it thus leaves
> the whitelist entry in the .ign file - now unnecessarily whitelist), or
> I replace it with a new entry of the same name (and again the script
> finds it and thus leaves the whitelist entry in the .ign file), we run
> into all kinds of potential hassles.
>
> I wish ClamAV had instead opted to whitelist based on the actual
> hexadecimal signature instead of the signature file:line:name, as that
> would make keeping the .ign files up-to-date for a script a much easier
> process.
>
> ClamAV, please consider this a feature request... :-)
This looks like a rather trivial awk or perl one-liner to reconstitute the .ign
file with current data rather than deleting it. Compare the array of *.ign
signature names against the changed signature files since the last check and if
the signature still exists, record it's new position (and new file name if it's
been promoted to main, for example). Obviously if the source file for the
signature hasn't changed, or a potential new location for it hasn't change
there's no need to scan.
As a minimum, ClamAV should rename the file to deactivate it, leaving it to the
admin to reconstitute it. Although I'd keep a copy of any .ign files in RCS,
personally.
So why would anyone wish to do this? Because a false positive may not be
entirely false. What is ans is not spam or phishing or what ever is subjective
and each of us finally has to decide that some signatures are simply
inappropriate and the vendor is not obliged to respond to claims of FP status,
anyway. None of us has signed a contract that says any signature vendor will
honor our requests to modify what we deem to be FP signatures.
Not that long ago when the ClamAV team was small and overworked I kept a file of
signature names on file and with each new signature change I ran a script to
delete those signatures from the official or unofficial sig files before
dropping them into the working directory. At the time I worked for a large
company that had an aggressive email marketing team who did not have the common
sense to test email campaigns against our own anti-spam tools let alone those of
others, and the expectation was I would consider any blocked content from our
own spam torrent to be FP's. This is absurd, of course, since our tools
indicated strongly what other sites would do with the spam, er, promotional
material :). So I focused on dealing with 50,000 bounces in 10 minutes time from
30,000 sites (tanks any server farm) instead of them cleaning up the sp^H^H
promo material.
Long winded explanation, but it predated the *.ign file and was persistent and
though for a bad idea, effective and easy to maintain. And entirely under my
control which satisfies my inner control freak.
dp
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
|
