[Bro] Cluster state synchronization
liburdi.joshua at gmail.com
Thu Oct 9 07:50:23 PDT 2014
As far as persistence goes, I had a similar need and ignored the
&persistent attribute; instead I manually append the data to a file
and then read the file into a table on bro_init. This seemed to work
well on some large scale (10 GB pcap) tests, but I haven't finished
the script to run in prod yet.
On Wed, Oct 8, 2014 at 11:17 AM, Damian Gerow <damian.gerow at shopify.com> wrote:
> On Wed, Oct 8, 2014 at 12:47 PM, Seth Hall <seth at icir.org> wrote:
>> > Done, and the end result is the same: sets are being updated slowly.
>> > For one CNAME in question, it took multiple queries and a few minutes for it
>> > to show up in the CNAMEs set.
>> Weird. Could you try removing the &persistent attribute from those
>> variables with it set? That attribute hasn't been used much ever,
>> especially in the past couple of years. It's probably going to be removed
>> before too many more releases too (replaced by something else).
> I can try, but we kind of depend on persistence: without it, Bro goes a bit
> nuts on startup until it sees all the DNS queries again. I've been toying
> with the idea of resolving each member of the list and adding to the
> appropriate address set during bro_init(), but that would still leave some
>> It would help if you had some traffic that showed this effect too. It
>> possible that there is something weird going on with your traffic that is
>> giving this appearance.
> The CNAME I mentioned above was a bad example: looks like the host was
> caching some aspects of it (namely, that it was a CNAME), so Bro never had a
> chance. I'll have another look at the network: we just had another false
> positive arrive, but the DNS log shows the query happening after the
> Thanks! Looks like the issue may be in the network itself.
> Bro mailing list
> bro at bro-ids.org
More information about the Bro