[Bro] Bro programming intro

[Tritium Cat]

The ability to work with items outside of BroNSM to me is useful and easier
than rewriting a BroNSM script and restarting a cluster when I want to look
at something differently or trim logs.  Searching for items and *guessing*
which requests are related is more time consuming.  Long term I can see
tweaking a Bro script to perform better.  I am very selective with using
email as an alert mechanism.

Using samples makes sense, as does uids, samples involve content and sound
larger than a simple int32?, but limiting those is fine as well, just as
you would the UIDs.  How do you plan to implement the sampling ?  By time
or by unique requests ?  Can an attack tool run a number of SQL injection
attempts and end the last 5 with something benign ?  I'd rather analyze the
specifics outside of BroNSM before going back and tweaking BroNSM.

Thanks for the /research link.



On Tue, Mar 19, 2013 at 9:12 AM, Vlad Grigorescu <vladg at cmu.edu> wrote:

>
> ________________________________________
> From:Tritium Cat [tritium.cat at gmail.com]
>
> > Simply buffering uids per Notice? seems much easier and less resource
> intensive than storing additional? samples.
>
> It's also much less useful. If I get an e-mail with a list of UIDs, I have
> to go query my http log before I can determine what action to take. If I
> get samples, I can make that decision immediately.
>
> I don't understand how tracking UIDs would be less resource intensive.
> Many SQL scanners I see attempt thousands of requests over separate UIDs.
> The way samples work is that you specify a number of samples per source IP.
> I believe the default is 5. I'd much rather have Bro maintain 5 samples per
> source instead of thousands of UIDs.
>
> > Where is the limit with tracking too much state or using too many cycles
> within the "IDS" ?
>
> One side note: Bro hasn't been labelled as an IDS for a while. Network
> Security Monitor strikes closer to what Bro has become.
>
> >  I am weary of inadvertently creating DoS conditions with a philosophy
> that may encompass every script I write in Bro.
>
> A fair concern, and one I think I addressed above. I would note that I
> haven't had any such problems with the scripts that ship with Bro.
>
> > I am still interested in a list of key papers on the internals if anyone
> has a few.
>
> http://bro.org/research
>
>  --Vlad
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20130319/a3eb76d0/attachment.html