[Emerging-Sigs] Another unknown exploit kit

Joel Esler jesler at sourcefire.com
Tue Oct 11 10:06:14 EDT 2011

On Mon, Oct 10, 2011 at 8:06 PM, Nathan <nathan at packetmail.net> wrote:

> There is some value here on convention then; if a flowbit is set in one
> rule file but checked in another we can have issues in disparity.
>  Convention might should be setting and checking of a flowbit constrained to
> a singular rule file where possible.
> No, having the flowbit set and check across different files is meaningless.
 They work exactly the same.  All the rule files are cached into memory on
start up, so it really doesn't matter what file they are in.

We are going to consolidate most of our "set" flowbits into one file, so
that should make use easier.

Speaking relative to performance I have noted flowbit-only checks are
> performance degrading by a heavy margin, so much so that performance-wise
> checking the Java stuff per content match may actually be faster than a
> flowbit.  Think content:" Java/"; http_header; coupled with the intended
> match versus flowbit checking.
> Yes, performance is bad, because you have no content check, so essentially
what needs to happen from the engine side, is the "rule" is ran more.  You
want to have a unique content match in every rule if possible.

> Perhaps we are inadvertently abusing flowbits, Joel any wisdom or insight
> here?

I haven't seen the rules you are talking about, so I am not sure what you
are asking me here.

Joel Esler
Senior Research Engineer, VRT
OpenSource Community Manager
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.emergingthreats.net/pipermail/emerging-sigs/attachments/20111011/6b57fcd7/attachment.html

More information about the Emerging-sigs mailing list