[Bro] Intel Framework Issues

Mark Buchanan mabuchan at gmail.com
Mon Nov 23 14:17:22 PST 2015


Could it be added as a flag in the intel feed data file?  Included in the
Metadata items - granted, this is a little more actionable than metadata,
but there is already meta.do_notice.  Could there be a meta.log_any_conn
(or something like that).  It could default to the full connection state
and then those who wanted to see any hits, could turn change the option for
those items they want any notification regardless of state.

I think it's valuable to provide the options, but can see both sides of the
fence.  Just like others, however, I'm not sure what the performance
penalty would be on enabling something like this by default.

Mark

On Mon, Nov 23, 2015 at 3:58 PM, Tim Desrochers <tgdesrochers at gmail.com>
wrote:

> I would have to agree with the majority here. I'd like the availability to
> turn it on per sensor or not. Some places are just more sensitive than
> others.
>
> Also I think looking for every connection outbound is very useful because
> it can show a compromised host on the network.
> On Nov 23, 2015 4:48 PM, "Azoff, Justin S" <jazoff at illinois.edu> wrote:
>
>>
>> > On Nov 23, 2015, at 3:48 PM, Seth Hall <seth at icir.org> wrote:
>> >
>> >>
>> >> On Nov 23, 2015, at 1:47 PM, Josh Liburdi <liburdi.joshua at gmail.com>
>> wrote:
>> >>
>> >> I think the most common gotcha for IP addresses is that they will only
>> appear in intel.log when they are a part of a successful TCP connection.
>> Unsuccessful TCP connections and non-TCP connections will not appear in the
>> log.
>> >
>> > Thanks for pointing that out Josh!  I do want to point out the
>> reasoning behind that as a default decision.  My thinking was that spoofed
>> packets could cause false hits and generally non-responded-to probes coming
>> from intelligence hosts aren’t all that interesting.  Is there general
>> agreement that that’s the right approach or should single packets hit on
>> intelligence items by default?
>> >
>> > I think there is a high bar to clear with adding that as default
>> behavior, but I’d like to hear from people actively doing incident response
>> on their thoughts.
>> >
>> > I should also point out that we can certainly include a script that
>> matches on non-complete connections with Bro even if we don’t load it by
>> default.
>> >
>> >  .Seth
>>
>>
>> IN_ORIG / IN_RESP may help with this
>>
>> seen IN_RESP in a failed outbound connection to a known phishing site,
>> useful to know
>>
>> seen IN_ORIG in a failed incoming port 22 connection from a known ssh
>> scanner, probably just noise.
>> seen in IN_RESP in a failed outbound port 22 connection to that same
>> known ssh scanner, useful to know
>>
>> Which I guess would mean something like
>>
>> event connection_i_forget(c: connection) {
>>     if(!Site::is_local_addr(c$id$resp_h)) {
>>         Intel::seen([$host=c$id$resp_h, $conn=c, $where=Conn::IN_RESP]);
>>     }
>> }
>>
>>
>>
>> --
>> - Justin Azoff
>>
>>
>> _______________________________________________
>> 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
>



-- 
Mark Buchanan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20151123/8882b635/attachment-0001.html 


More information about the Bro mailing list