The Bro IDS is great at analyzing network traffic, not to mention it’s very capable at detecting and logging issues that it finds in your network traffic. It’s amazing that an open-source project has progressed this far. This post covers configuring Bro and running it.

Let’s review what we have covered in part one and part two of this guide:

  • Prerequisites for Bro IDS are installed, including:
    • PF_RING
    • Other needed packages
  • OS settings are adjusted, including:
    • Firewall/IPTables
    • Memory/buffers settings are adjusted
  • Bro is compiled
  • Plugins are compiled and installed, including:
    • PF_RING
    • Setcap (which enables some permissions for non-root users)

This section will go into configuring various settings in Bro, then starting Bro. We’ll also explore how to check on the health of Bro.

Navigate to the following directory by running:

You see there are several .cfg files. The ones we will modify are networks.cfg, broctl.cfg, and node.cfg.

The file networks.cfg tells bro what subnets you expect to see on your network. This will usually include private subnets such as, and an organization’s public IP addresses. Modify the file by using your favorite text editor (such as vim) to reflect the subnets your organization owns and uses.

The broctl.cfg file contains settings such as emailing notifications, where to write log files to, and so forth. If you followed the previous post, you had also modified this file to run the setcap plugin. I recommend modifying this file to tell Bro to write the log and spool files to a separate partition from that of the operating system.

Broctl.cfg Settings

Most of these settings will need to be adjusted in a text editor (such as vim) according to your setup. I will point out the settings that need to be modified and describe what each node function does.

The manager is what runs and keeps tabs on the entire cluster. It also collects and writes logs to disk if there is no separate logger process. Small clusters don’t normally need loggers.

The proxy process helps coordinate information such as variables and state between the workers. Some people like to run the proxy on the same machine as the manager. Others like to run a few proxies on the workers themselves. And in large clusters, proxies will run on their own machines. You will need to adjust the number of proxies and where they are according to optimize your setup. For this example, two proxy processes will run on the same box as the manager.

Now we come to the workers. These process the traffic they receive, so they tend to be pretty beefy boxes. The lb_method specifies how Bro will retrieve packets from the NIC, in this case pf_ring. lb_procs sets how many processes to run on the machine. pin_cpus will specify which cpus the processes will run on. Since in this example the worker box has 24 logical cores, 22 cores will be used for Bro, thus leaving 2 cores for the operating system and other processes. Last, the interface specifies which network card’s interface Bro will listen on.

Save the file and exit.

Protocol Analysis

Now you can choose which scripts Bro will use to analyze and log traffic. The default settings are pretty good, but I would also recommend turning on the SMB scripts as well as SMB is notorious for being an attack vector for malware. Open up the local.bro file in a text editor by running:

Near the bottom, uncomment the line

SSL scripts can be more cpu intensive. If your later see you have limited CPU to spare, you might consider disabling these scripts.

Starting Bro

Now the milestone you’ve been waiting for! Time to start up bro. From the manager run:

This opens up the broctl CLI. The –help will give you a list of commands you can run. I’ve outlined a few common ones below:

check. Checks to make sure your configurations are valid.

status. Checks if the manager can communicate with the other machines in the cluster, and the status of the processes on them.

deploy. Copies the Bro program and configuration files from the manager and installs it on the other machines, then starts the appropriate Bro processes.

netstats. Gives packet statistics per worker process, including how many were dropped after they were received by the NIC.

capstats. Gives an average throughput per worker. I would avoid this as it eats up a ton of CPU and drops a lot of packets.

diag. Gives basic diagnostic output about the system such as why a process failed to start.

Start, stop, and restart are also common self-describing flags.

From the broctl prompt, run

This will initiate SSH connections, install Bro on the remote hosts, and initiate SSH connections back to the manager. If all goes well, you should not see any errors on the manager when running this command. If you do, check the “diag” output to narrow down what might have gone wrong.

From the broctl prompt, you can run “status” to see if the manager is able to communicate with the worker processes. Running netstats tells you if the NIC has dropped packets or not. If you get a response back, then the workers can communicate back to the manager.

To ensure everything is running,  navigate to the log directory and list the files by:

If you see files such as conn.log, then you have successful started Bro and are analyzing traffic. Congratulations!

This concludes part three of four of this guide. The next post helps you through some troubleshooting steps and other adjustments.