[Bro] Bro programming intro

Tritium Cat tritium.cat at gmail.com
Tue Mar 19 08:46:03 PDT 2013


Ok. I am skeptical of how much emphasis is placed on doing things within
BroIDS.  Simply buffering uids per Notice? seems much easier and less
resource intensive than storing additional? samples.  Where is the limit
with tracking too much state or using too many cycles within the "IDS" ?  I
am weary of inadvertently creating DoS conditions with a philosophy that
may encompass every script I write in Bro.

I am still interested in a list of key papers on the internals if anyone
has a few.



On Tue, Mar 19, 2013 at 8:13 AM, Seth Hall <seth at icir.org> wrote:

>
> On Mar 18, 2013, at 8:03 PM, Tritium Cat <tritium.cat at gmail.com> wrote:
>
> > I want to modify the SQL Injection detection in
> policy/protocols/http/detect-sqli.bro to include a vector that tracks the
> associated http request uids and includes them in an additional log field.
>  After getting it working I would like to apply it generally to other
> Notices such as SSH Password_Guessing.
>
> The upcoming release actually results in this script getting rewritten a
> bit because of a rewrite of the metrics (now measurement) framework.  The
> new version actually keeps samples of the requests.  It will be relatively
> easy to write your own script that tracks uid's instead of urls but the
> benefit to sampling the urls is that if you have Bro send you email for the
> notice it will add those sample urls to the email (it's been very
> convenient for determining if something is a false positive without even
> searching logs).
>
> Otherwise, with the metrics framework in 2.1 there isn't a good way to do
> it.
>
>  .Seth
>
> --
> Seth Hall
> International Computer Science Institute
> (Bro) because everyone has a network
> http://www.bro.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20130319/d007f13e/attachment.html 


More information about the Bro mailing list