The Bro Analyzers operate on the principle that port number is not a good indicator of protocol. But the filtering step does exactly the opposite.
For example, the filter applied when the default brolite.bro policy file is used is-
((((((((((port telnet or tcp port 513) or (tcp[13] & 7 != 0)) or (tcp dst port 80 or tcp dst port 8080 or tcp dst port 8000)) or (tcp src port 80 or tcp src port 8080 or tcp src port 8000)) or (port 111)) or ((ip[6:2] & 0x3fff != 0) and tcp)) or (udp port 69)) or (port 6666)) or (tcp port smtp or tcp port 587)) or (port ftp)) or (port 6667)
Thanks to the filtering step,
1. Bro will analyze some traffic that didn't belong to any of the 'relevant' protocols until it realizes that it can safely be discarded, and
2. Bro will not analyze traffic that belonged to one of the relevant protocols because it was filtered out for not being used on the standard port.
Is this true? And if so, is this an okay side-effect to have of the filtering step?
I thought the same thing when I first started looking at Bro and it's
dynamic protocol detection (dpd) about 2 months ago. Take a look at the
dpd wiki page which gives a good description of how it works. It also
states:
when loading dpd you may need to change the filter to include all
packets, e.g. on the command line:
bro -f "tcp or udp or icmp" ...
when loading dpd you may need to change the filter to include all
packets, e.g. on the command line:
bro -f "tcp or udp or icmp" ...
Okay, so it makes sense to use capture_filter as-it-is when you are not using DPD; and to disable capture_filter (using "bro -f") if you are using DPD. In the latter case, you end up analyzing all packets which causes an extra performance cost of about 13.8% [with given parameters, Section 6.1, USENIX'06 paper].
The same section of the paper also says that the runtime of the Bro system exceeds the duration of the trace, indicating that we require "multiple NIDS instances in live operation".
"Multiple NIDS instances in live operation"- has this been discussed anywhere else? With the filter disabled, this would be very useful. Is it as simple as splitting up your policy file among different machines running Bro or is there more to it?
when loading dpd you may need to change the filter to include all
packets, e.g. on the command line:
bro -f "tcp or udp or icmp" ...
Okay, so it makes sense to use capture_filter as-it-is when you are not
using DPD; and to disable capture_filter (using "bro -f") if you are
using DPD. In the latter case, you end up analyzing all packets which
causes an extra performance cost of about 13.8% [with given parameters,
Section 6.1, USENIX'06 paper].
The same section of the paper also says that the runtime of the Bro
system exceeds the duration of the trace, indicating that we require
"multiple NIDS instances in live operation".
"Multiple NIDS instances in live operation"- has this been discussed
anywhere else? With the filter disabled, this would be very useful. Is
it as simple as splitting up your policy file among different machines
running Bro or is there more to it?
Someone else can correct me if I'm wrong, but I think that you are needing to setup a clustered environment with managers, proxies, and workers. The user manual briefly mentions something about this in the installation section, but my limited understanding of how it works comes from reading the scripts located at $BROHOME/share/broctl. My use of bro is strictly for offline processing so I have yet to really pay attention to it other than starting bro in standalone mode.