Status, performance, and future directions

Bro has operated continuously since April 1996 as an integral part of our site's security system. It initially included only general TCP/IP analysis; as time permitted, we added the additional modules discussed in § 6, and we plan to add many more.

Presently, the implementation is about 22,000 lines of C++ and another 1,900 lines of Bro (about 1,650 lines of which are ``boilerplate'' not specific to our site). It runs under Digital Unix, FreeBSD, IRIX, SunOS, and Solaris operating systems. It generates about 40 MB of connection summaries each day, and an average of 20 real-time notifications, though this figure varies greatly. While most of the notifications are innocuous (and if we were not also developers of the system, we would suppress these), we not infrequently also detect break-in attempts. Operation of the system has resulted so far in 4,000 email messages, 85 incident reports filed with CIAC and CERT, a number of accounts deactivated by other sites, and a couple incidents involving law enforcement.

The system generally operates without incurring any packet drops. The FDDI ring it runs on is moderately utilized: a recent trace of a 2-3PM busy hour reflects a traffic level of over 8,800 packets/sec (25 Mbps) sustained for the full hour, with peaks exceeding 15,000 packets/sec. However, the packet filter discards a great deal of this, both due to filtering primarily on SYN, FIN, or RST control bits, and because only about 20% of the traffic belongs to networks that we routinely monitor (the link is shared with a large neighbor institution). During a busy hour, the monitor may receive 300,000 packets matching the filter, with peaks of 200/sec.

In order to make a preliminary assessment of the system under stress, we ran it for a thirty-minute period without the ``interesting networks'' filter, resulting in a much higher fraction of traffic accepted by the packet filter. During this period, the filter accepted an average of 640 packets/sec, with peaks over 800/sec. However, the filter also reported 364 dropped packets. (We note that the hardware platform used is no longer state-of-the-art.)

In addition to developing more application analysis modules, we see a number of avenues for future work. As discussed above, compiling Bro scripts and devising mechanisms to distribute monitoring across multiple CPUs have high priority. We are also very interested in extending BPF to better support monitoring, such as adding lookup tables and variable-length snapshots. Another interesting direction is to add some ``teeth'' to the monitoring in the form of actively terminating misbehaving connections by sending RST packets to their endpoints, or communicating with intermediary routers. This form of ``reactive firewall'' might fit particularly well to environments like ours that need to strike a balance between security and openness.

Finally, Bro is publicly available in source-code form (see https://www-nrg.ee.lbl.gov/bro-info.html for release information). We hope that it will both benefit the community and in turn benefit from community efforts to enhance it.