[Bro] Bro programming intro

Tritium Cat tritium.cat at gmail.com
Tue Mar 19 09:50:34 PDT 2013


I have to point out what I interpret as not answering the question about
how to buffer data across time.  Not sure how to interpret that other than
"go figure it out yourself" or wait for $next_release where it will exist
in an altered form :p   Maybe what I'm doing is stupid but maybe it will be
clever.



On Tue, Mar 19, 2013 at 9:41 AM, Tritium Cat <tritium.cat at gmail.com> wrote:

>
> 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/b48d654c/attachment.html 


More information about the Bro mailing list