[Bro] Intel Framework Issues

[Azoff, Justin S]

> 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