Adding options to bro managed by broctl

We’d like to start bro with a tcpdump filter of, for example, -f ‘net 1.0.0.0/24 or port 443’. We use broctl to manage the bro process. Where is the appropriate place to add the desired filter so that broctl appends it to any instantiation of a bro process?

Thanks for your help

Add:

broargs = -f 'net 1.0.0.0/24 or port 443'

to your broctl.cfg file.

James

That will work, but technically it might be a bit better to do something like this...

redef capture_filters += {
  ["watched network"] = "net 1.0.0.0/24",
  ["https"] = "port 443"
};

If you build up what you want to capture this way it gives Bro the chance to automatically build your BPF filters for you, including checking each component of your filter for mistakes which it will then detect at startup and tell you which component of your filter failed. If you use the above lines to indicate the traffic you'd like to allow into Bro, you can also set restriction filters to limit something a bit. For instance, in that 1.0.0.0/24 subnet you might want to ignore a single host. You could implement that by adding the following lines...

redef restrict_filters += {
  ["unmonitored host"] = "host 1.0.0.54"
};

The filter that would ultimately be constructed by those lines is...
  ((port 443) or (net 1.0.0.0/24)) and (host 1.0.0.54)

One thing to be careful with this though is that generally when you take the stance that you are doing filtering you have to be really careful to understand your traffic. If you have any traffic with MPLS or VLAN tags, the filters I gave won't allow that traffic through. If you're interested in doing ARP analysis you won't see those packets either. Same goes for IPv6.

Filtering is an area where we've tried to make things simple by running a fully open filter, there are a lot of dragons when you stray from that path. :slight_smile:

  .Seth

Seth:

Thanks for the direction. We ended up leveraging the capture_filter as you described. Our traffic is MPLS so the capture filter is a little more complicated but we’ve got it working well. If anyone else needs it, here’s what we’ve done to use capture_filters in an MPLS environment. We have anywhere from 0-2 MPLS labels on our traffic so:

redef capture_filters += { [“inet_fltr”] = “(net 1.0.0.0/24 or port 443) or (mpls and (net 1.0.0.0/24 or port 443)) or (mpls and mpls and (net 1.0.0.0/24 or port 443))” };

There may be some better way to recursively pop any number of MPLS labels but this seems to work ok in our environment.

Ultimately, we intend to have our tap aggregator pop the MPLS labels and apply any necessary filters but MPLS label popping is only roadmapped at this point on our tool.

Thanks