I have a two-worker cluster running on an Ubuntu VM. Bro was installed from the packages provided by OpenSUSE.
Ubuntu 16.04.4 LTS
Bro 2.5.3
BroControl Version 1.7.
Aside from commenting out most “@load protocols/xxx” lines, I have made minimal changes to the configuration.
I am debugging capture filters but unfortunately broctl print capture_filters throws an error. ‘broctl status’ works fine.
broctl status
Name Type Host Status Pid Started
manager manager localhost running 11704 10 Apr 15:09:24
proxy-1 proxy localhost running 11880 10 Apr 15:09:25
worker-1 worker localhost running 11937 10 Apr 15:09:27
worker-2 worker localhost running 11938 10 Apr 15:09:27
broctl print capture_filters
manager <error: cannot connect to 127.0.0.1:47761>
proxy-1 <error: cannot connect to 127.0.0.1:47762>
worker-1 <error: cannot connect to 127.0.0.1:47763>
worker-2 <error: cannot connect to 127.0.0.1:47764>
I added ‘Debug=1’ to broctl.cfg, re-ran the commands and looked in /opt/bro/spool/debug.log but found no additional information.
Perhaps I am still missing some software? Incompatible version of python-broccoli (came from Ubuntu)?
David
David,
I have started using a different technique for debug/dumping now:
I tap into "event reporter_info"
rough example :
$cat a.bro
redef capture_filters += { ["my-net"] = "(vlan and not net 1.2.0.0/16) or not net 1.2.0.0/16", } ;
event bro_init()
{
local _msg = "" ;
for (a in capture_filters)
{
_msg = fmt ("capture-filters: %s-> %s", a, capture_filters[a]);
event reporter_info(network_time(), _msg, peer_description);
}
}
then run as: bro -i eth0 ./a.bro
$cat reporter.log | fgrep capture-filters
you should see the output.
event reporter_info is a good event to tap for dumping info in a cluster setup.
Basically I've used it as a cluster version of "print fmt (" used in standalone.
Hope this helps,
Aashish
You can just
Reporter::info(fmt ("capture-filters: %s-> %s", a, capture_filters[a]));
Have you verified that Bro is listening on those ports?
(e.g. "netstat -ltn")
Good question. Alas, 'netstat' and 'lsof' show bro listening on those ports.
Thanks, Aashish. It does work.
Thanks, Justin, this works well too.
In both cases, when I re-run bro, the order of pieces printed is different. I don't know if this order is an artifact, or what, but I think the internal order is important -- non-vlan filters first and vlan filters after....
The thing I am trying to troubleshoot is that if I concatenate on one line all of the pieces, the filter works as expected. If I do this:
redef capture_filters = { ["subnets"] = "(not (src net aaa.bbb.0.0/16 or src net aaa.ccc.0.0/16 or src net ddd.jjj.0.0/16 or net eee.hhh.ggg.0/28)) or (vlan and (not (src net aaa.bbb.0.0/16 or src net aaa.ccc.0.0/16 or src net ddd.jjj.0.0/16 or net eee.hhh.ggg.0/28)))" };
it works as expected. However if I do this (much neater looking):
redef capture_filters = {
["subnets"] = " (not (src net aaa.bbb.0.0/16 or src net aaa.ccc.0.0/16 or src net ddd.jjj.0.0/16))",
["iris-1"] = " (not (net eee.hhh.ggg.0/28))",
["subnets_V"] = "(vlan and (not (src net aaa.bbb.0.0/16 or src net aaa.ccc.0.0/16 or src net ddd.jjj.0.0/16)))",
["iris-1_V"] = "(vlan and (not (net eee.hhh.ggg.0/28)))"
};
I do not get the same behavior.
David
Use of vlan in bpf filters can be problematic. See: https://stackoverflow.com/questions/31136182/libpcap-filter-strings-using-vlan-are-behaving-weirdly
I don’t think the “much neater looking” bpf fragments are necessarily being applied in the same order that you specify them as the order of traversal through a table is not specified.
Hope this helps.
Oh, Aashish forwarded this to me off list and I didn't realize it was actually posted here. I'll give a version of the email I sent off list to hopefully explain this situation in more detail for everyone else too.
The fact that these filters have vlan tags makes this all super complicated (as Jim pointed out, thanks!). Generally I recommend that if people have vlan tags, they don't try to do filtering because it's going to be seriously mind bending.
Unfortunately, at the moment I have a hard time make a suggestion for a filter if you want to use capture_filters, as you've discovered that can be complicated based on how filter fragments are combined. You may want to use the full filter you wrote and use that as a 'cmd_line_bpf_filter' variable. I wouldn't normally recommend using the 'cmd_line_bpf_filter' variable because it closes some doors of functionality but there isn't a good way to avoid it in this case.
redef cmd_line_bpf_filter = "(not (src net aaa.bbb.0.0/16 or src net aaa.ccc.0.0/16 or src net ddd.jjj.0.0/16 or net eee.hhh.ggg.0/28)) or (vlan and (not (src net aaa.bbb.0.0/16 or src net aaa.ccc.0.0/16 or src net ddd.jjj.0.0/16 or net eee.hhh.ggg.0/28)))";
I did want to make one other comment about the filter. You almost certainly don't want to use "src" or "dst" in your filters. Because that filtering is done at the packet level, even if the filter works correctly it means that you'll only see a single direction of traffic which will also be bad for Bro. Most of Bros functionality expects to see both directions of conversations and won't work as well if both sides aren't there. So the line I would actually recommend running is this...
redef cmd_line_bpf_filter = "(not (net aaa.bbb.0.0/16 or net aaa.ccc.0.0/16 or net ddd.jjj.0.0/16 or net eee.hhh.ggg.0/28)) or (vlan and (not (net aaa.bbb.0.0/16 or net aaa.ccc.0.0/16 or net ddd.jjj.0.0/16 or net eee.hhh.ggg.0/28)))";
VLAN tags and BPF filtering are never any fun.
.Seth
Jim,
Thanks very much.
That is a helpful article. I had known about the VLAN pitfalls from bitter experience and think I navigated around them in the way I intended in the original ‘long’ version of the filter. I think the opening line summarizes pretty well "vlan is weird."
I am pretty convinced now that the fragments are being applied in some non-deterministic order, which makes them useless for my application, unfortunately.
David