[Bro] Intel Framework Issues

Kellogg, Brian D (OLN) bkellogg at dresser-rand.com
Mon Nov 23 13:20:52 PST 2015

I'm interested on non-complete connections being logged; CrowdStrike has a script to enable this already and I use it.  It’s a way of finding compromised hosts out there that have lost contact with their CnC for whatever reason.  But, I do not run a lot of indicators in Bro.  Most open source intel lists create too many FPs to be used as a good primary indicator of badness in my experience.  An option to enable it per indicator/indicator type or both may be a nice option.


-----Original Message-----
From: bro-bounces at bro.org [mailto:bro-bounces at bro.org] On Behalf Of Seth Hall
Sent: Monday, November 23, 2015 3:48 PM
To: Josh Liburdi
Cc: Disha Bora; bro at bro.org
Subject: Re: [Bro] Intel Framework Issues

> 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 Hall
International Computer Science Institute
(Bro) because everyone has a network

Bro mailing list
bro at bro-ids.org

More information about the Bro mailing list