[Bro] Intel Framework Issues

Azoff, Justin S jazoff at illinois.edu
Mon Nov 23 13:40:16 PST 2015

> 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

More information about the Bro mailing list