[Bro] Emerging Threats signatures on Bro ids ?

Martin Holste mcholste at gmail.com
Thu Aug 16 11:55:10 PDT 2012


So, here's the intel feed I'd want:
{
  host:<some bad hostname pattern, e.g. 'example.com'>
  uri: <some bad URI pattern, e.g. 'in.cgi'>
  uri_params: <array of URI parameters that constitutes "badness",
e.g. [ 'id', 'os', 'affid' ]
  headers: <hash of header content of badness, e.g. { 'user-agent': 'Presto' },
  etc...
}

As you can probably see, yara would be a great fit for something like this.

On Thu, Aug 16, 2012 at 1:28 PM, Matt Jonkman
<jonkman at emergingthreats.net> wrote:
> 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
>
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro




More information about the Bro mailing list