[Bro] BRO on the endpoint, how to manage.

[Samuel Oehlert]

Are you attempting to monitor traffic coming to and from the hosts? If so,
wouldn't it be easier to keep bro at the network level and require VPN
connections for remote employees?

Another possible option if you're just looking for some general endpoint
information is to try out the bro-osquery connection: (
https://github.com/bro/bro-osquery)

Just a little more food for thought.

-Sam

On Wed, Mar 8, 2017 at 5:53 PM, Dan Ecott <dan.ecott at gmail.com> wrote:

> Some responses inline. I may try and leverage AWS lambda triggers on git
> commits and Jamf to get new scripts down to the laptops somehow.
>
> Thanks for your responses. I will check back in if I make any good
> progress.
>
> Dan.
>
> On Wed, Mar 8, 2017 at 11:55 AM Mike Dopheide <dopheide at gmail.com> wrote:
>
>> I don't know anyone else that's tried this, but it's an interesting
>> thought experiment.  A few initial thoughts in no particular order...
>>
>> (1) Given that Bro can be relatively CPU intensive, your developers will
>> likely hate you for having something like that running on the same system
>> where they're trying to do their work.  I'd suggest setting up a one-off
>> example and getting some real data on performance impact.
>>
>
> Definitely going to look at how this impacts the use of the laptops.
> Initial assessments on my own show that  the bro processes don't use
> anything more than 2% CPU with the out of the box scripts.
>
>>
>>
>> (2) Cool idea!
>>
>
> If it works. :-)
>
>>
>> (3) I'd definitely run these as one-off Bro instances rather than trying
>> to make it a cluster.  To start cluster communication doesn't traverse
>> secure protocols.  However, that means you'll have to build up your own
>> means of getting the log data, alerts, and checking on process status.
>>
>
> Yes. We run splunk forwarder on the laptops too and I sym link the bro
> logs into /var/log which splunk forwards out for indexing. Process checking
> is another thing I have to figure out.
>
>>
>>
>> (4) Related to (3) most of us use Bro to passively monitor network
>> links.  If your Bro process is sending data back out over the same network
>> connection that it's monitoring you'll need to be very careful not to build
>> a snowball effect.
>>
>
> Agreed. Gotcha.
>
>>
>>
>> (5) We've been tracking our Bro policies in git for some time now, works
>> great.
>>
>
> cool.
>
>>
>>
>> (6) Do your developers run a fairly standard system configuration on
>> their endpoints or would you have to potentially build Bro for a lot of
>> different environments?
>>
>
> Yes. This is going to be running on modern MacBook Pro laptops fully
> loaded. Should be no issues.
>
>>
>>
>> (7) Maybe you could have Bro running on the endpoint only when the
>> developer is traveling or otherwise on a less trusted (unmonitored) network?
>>
>
> Worth thinking about.
>
>>
>> -Dop
>>
>>
>>
>> On Wed, Mar 8, 2017 at 5:50 AM, Dan Ecott <dan.ecott at gmail.com> wrote:
>>
>> Hello.
>>
>> I am exploring whether Bro can work for my company in a particular use
>> case. What I would like to do is run Bro sensors on developer laptops,
>> centrally manage the Bro scripts that run on those end points and ensure
>> the Bro process is always running.
>>
>> What is the best way to run a deployment like this? Has it been done
>> before? Bro Cluster doesn't look like the right solution.
>>
>> As far as managing the scripts, I was thinking of building an AWS code
>> pipeline where I can promote scripts through a Git repo, then have a
>> process whereby approved scripts get pushed out to the end points quickly.
>>
>> Any help on this would be appreciated.
>>
>> Dan.
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20170309/96605812/attachment.html