Hi there,
On Tue, 15 Mar 2022, Laurent S. via clamav-users wrote:
On Tuesday, March 15th, 2022 at 00:36, Micah Snyder wrote:
Starting with our own new language would let us maintain do that
but make it easier for new analysts to train up on ClamAV.
I don't see at all the advantage of using a different, less used
language. I don't know many people looking forward to learn a new
language that is quite specific to one software and used more or
less nowhere else.
Well I can understand that features which are unique to ClamAV might
demand something more flexible than the Yara specification, although I
don't profess to have great insight into that. I wonder if this means
there's a case for "ClamAV *extensions* to the Yara language" or some
variation on that theme. I guess it wouldn't be too difficult to make
the extensions sufficiently non-Yara like to avoid clashes with future
developments of Yara itself. In case it isn't obvious we already have
a "ClamAV *version* of the Yara language" so this suggestion might not
be as outrageous as it seems.
using Yara's engine in clamav directly is something that has been
brought up time and again. It is possible. My understanding is that
the reason ClamAV's yara support isn't done this way is that it
would require a second pass over the file with a Yara's pattern
matcher, after ClamAV's pattern matcher, and that the performance
concern made it make more sense to try and load yara rules into
ClamAV's matcher instead.
Speaking selfishly I wouldn't be greatly inconvenienced by an increase
in the scan times (even if it doubles) caused by separating the Yara
engine from the ClamAV engine. That's because I only scan mail, and
the clamd server is well on top of it. I can understand that people
who scan filesystems might have a different point of view; maybe both
could be accommodated with a config option.
I honestly don't have any numbers to back up this argument. It
sounds reasonable, but I'd love to see the numbers.
I occasionally run more than one clamd instance and I've seriously
considered running a separate one purely so that that Yara rules are
kept separate from the rest. I always log scan times. It will be a
bit fiddly, but when I get a minute I'll set something up to try to
give you some numbers.
One big reason I like to use ClamAV is that it's possible to add
other sources of signatures. Lots of people use the sanesecurity
ones. I add a lot of my own.
+1
Finally, unashamed repetition:
(1) a plea for a way to test rules before they go live;
(2) another plea for a parser which is good at its job;
(3) a way to specify that a rule is to match in
(a) mail headers only or
(b) mail body only or
(c) both;
and lastly
(4) it would be great to have a way to reload rulesets separately so
it isn't necessary to reload ten million signatures when you've only
added one Yara rule, only then to find clamd crashes the first time it
tries to scan anything because you broke that rule. I understand this
might be asking a lot, and a decent parser which prevents attempts to
load garbage rules (point 2) would do a lot to alleviate this pain.
--
73,
Ged.
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
