[Bro] Emerging Threats signatures on Bro ids ?

Matt Jonkman jonkman at emergingthreats.net
Thu Aug 16 11:28:09 PDT 2012


On Wed, Aug 15, 2012 at 10:36 PM, Seth Hall <seth at icir.org> wrote:
> I think there are some fundamental issues at play here, and integrating the EmergingThreats signatures in this manner is probably not the right way to go.
>
> Some comments on the script:
>
>     - That et_performancepenalty variable won't really help since just handling the packet_content event is what will cause most of the overhead.
>
>     - Your other variables such as sid2014029, et_trojan, and et_useragent are not actually providing any benefit because you aren't ordering the conditions correctly to allow for short circuiting.
>
>     - You are accessing c$http$user_agent inside of http_header event handlers which will have several problems by itself.  That variable won't be filled out until the user-agent header is seen which means you will be filling the reporter log with a lot of error messages and possibly causing memory leaks because the event handler will be failing due to an attempt to access a null field in the record.  It's also something that could just be checked at a later point (like in http_message_done).
>
>
> Those three big issues were just from a quick glance through the code.  There are better and more flexible ways of approaching this, but a big part of the problem is the way the intelligence from emerging threats is distributed is not suitable as-is for Bro right now.
>
> The best thing that could come out of our community now is guidance for EmergingThreats on how to provide their data in a way that is less product specific.  The signatures are written for Snort and Suricata; trying to jam them into Bro without thinking hard about the problem is probably going to be a waste of effort unfortunately.

We're definitely all for that! We already distribute our rules in
forms other than Snort and Suricata for a few customers. We're set up
well on the backend to manage multiple languages.

I have to claim significant ignorance of how the Bro language looks
and is structured. But very eager to dive in and see what we can do.

We tried this years ago as I mentioned, and the impact we had on
performance wasn't good. What is essentially the approach we need to
take to put the same intel into a form Bro can use effectively? Do we
have to not think "one bro sig == one suricata sig"?

Thanks Seth!

Matt


>
>   .Seth
>
> --
> Seth Hall
> International Computer Science Institute
> (Bro) because everyone has a network
> http://www.bro-ids.org/
>
>
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro




More information about the Bro mailing list