Hi Torge, You can use the ALLMATCHSCAN command for clamd, this will return all the signatures that matched on the file rather than just the first.
Tom On Tue, Feb 18, 2014 at 10:42 AM, Torge Husfeldt <torge.husfe...@1und1.de>wrote: > Hi, > > We are scanning webhosing-files from a relatively large user-base (~5M) > using the clamd-engine and signature databases tweaked for the least > possible false-positives. > > In this context we have 2 use-cases which apparently aren't met by the > current implemetation. > In both cases the remedy would boil down to stop clamd from > short-circuiting. > The current logic AFAICT is "on pattern match report and stop looking" > indistinctly of which pattern matched. > This means in practice that an "untrusted" pattern could mask a "trusted" > pattern and prevent the more severe action associated with the trusted > pattern from being triggered. > What we would need is to change this behavior (at least for a configurable > subset of patterns) so that the "trusted" pattern-match is always reported > regardless of any prior "untrusted" match. > > Questions: > Am I the only one having this issue? > Am I missing some configuration-switch? > Would anyone be interested in implementing this? > Can anyone point me to where I would look first if I wanted to implement > this? > > Use Case 1: > "evaluate patterns from third parties" > Our current db only contains a fraction of clamav's official signatures > and incorporating more of them under the above "0 FP" policy is a pain in > the backside. > Same for LMD (linux malware detect) signatures. > > Use Case 2: > "suspicious patterns" > e.g. > ".htacces having ErrorDocument poiting to a fully qualified URL" > If the domain of that same url points to the same webspace this is fine, > if it is on some sort of domain blacklist it is malicious, everything else > has to be checked manually. > When I try to implement this logic as a set of signatures, I risk a lot of > false-negatives (suspicious pattern hits where trusted pattern would have > matched, too). > Same goes for "sig for obfuscation-technique" vs "sig for known obfuscated > content". > > Thanks in advance > > P.S.: I know there are workarounds (like: scan twice), but I'm explicitly > reaching out here to determine if it would make more sense to fix this > issue at the root. > > -- > Torge Husfeldt > > Senior Anti-Abuse Engineer > Zentrales Abuse-Department (1&1 GMX Web.de) > > 1&1 Internet AG | Brauerstraße 50 | 76135 Karlsruhe | Germany > Phone: +49 721 91374-4795 | Fax: +49 721 91374-2982 > E-Mail: torge.husfe...@1und1.de | Web: www.1und1.de > > Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 6484 > > Vorstand: Ralph Dommermuth, Frank Einhellinger, Robert Hoffmann, Andreas > Hofmann, Markus Huhn, Hans-Henning Kettler, Uwe Lamnek, Jan Oetjen, > Christian Würst > Aufsichtsratsvorsitzender: Michael Scheeren > > Member of United Internet > > Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte > Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind > oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den > Absender und vernichten Sie diese E-Mail. Anderen als dem > bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, > weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. > > This E-Mail may contain confidential and/or privileged information. If you > are not the intended recipient of this E-Mail, you are hereby notified that > saving, distribution or use of the content of this E-Mail in any way is > prohibited. If you have received this E-Mail in error, please notify the > sender and delete the E-Mail. > > _______________________________________________ > Help us build a comprehensive ClamAV guide: > https://github.com/vrtadmin/clamav-faq > http://www.clamav.net/support/ml > -- Senior Research Engineer SourceFire Vulnerability Research Team _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/support/ml
