Thursday, November 12, 2015

Announcing the Bro Future Fund

Bro has seen exponential growth over the past five years since the release of version 2.0. This is seen in the growth of attendees and organizations at BroCon, Twitter followers, IRC channel usage, downloads, and more. Much of the credit to this surge of activity goes to the National Science Foundation, which at a key time provided us with the support for software engineering the project had long needed, and which continues to fund the NSF Bro Center to help NSF communities and higher-ed. Help us with the next stage of our growth. Become a precious metal sponsor and investor in the Bro Future Fund.

In this year, our 20th anniversary, we joined Software Freedom Conservancy.  This alliance will support our continued growth, further build the community of support, and stay true to our open source heritage.  We have likewise formed a leadership steering team drawing upon community representatives that depend upon Bro for their day-to-day operations from a range of constituents (public sector, education, private sector).

We understand that our community depends upon us; we likewise depend upon the community. We want to continue to develop a great software system, but see an even brighter future ahead. Imagine a vibrant community with contributions to Bro from all over the world; not just one annual conference but a wealth of events around the world; Bro training/sharing workshops with community grants and awards; a surplus of illuminating training materials and high-quality, real time support.  We see this demand on a daily basis, but we need your help to make it a reality.

Joining the Conservancy is an important first step to fulfill this vision of a larger, vibrantly engaged, community-driven project. Going further, we need resources to fuel new undertakings, to provide stability to our development efforts, and to anchor plans for the next decade of development. Consider becoming a sponsor organization today and strike the spark for the next great adventure!

Precious Metal Levels

All annual sponsors are recognized with their logos on our sponsorship page, with particular prominence going to the highest levels. Bronze sponsorship starts at $10,000 per year, Silver at $25,000 per year, Gold at $50,000 per year, and Platinum at $100,000 per year. Contact us at to discuss becoming a precious metal sponsor or the unique Singular Sustainer sponsor.


In addition to these annual sponsorships meant to sustain and grow the project, we also gladly accept donations of any size through PayPal from both individuals and organizations. Please see our web page for more information. Everything helps.

Wednesday, November 4, 2015

Announcing Bro's Packet Bricks

The Bro Development Team is announcing the release of Packet Bricks.

Packet Bricks is a Linux/FreeBSD daemon that is capable of receiving and distributing ingress traffic to userland applications. It uses netmap's I/O module to capture traffic and netmap pipes to forward packets to target applications.

Packet Bricks is available on our Github page. The project is in an experimental phase of development. We do not recommend it for production use. Feedback and bug reports may be directed to

Wednesday, October 14, 2015

Bro News #6

Bro News #6

Welcome to the 6th Bro not-monthly newsletter. We renamed Bro Monthly to Bro News. Instead of forcing a monthly newsletter we give you updates when there is really something to say. This time we cover the following topics:
  • End of Bro-year: Another year of the NSF project funding Bro has ended. Read about all the awesome things we've accomplished.
  • Bro Meet-ups: our category for Bro related gatherings and groups.
  • Bro Commits: Bro v2.4.1 is here. Get your improved Bro 2.4.
  • Bro Internals: Bro has joined Software Freedom Conservancy

End of Bro-year

Most of the things we do we are only able to thanks to the generous funding granted by the National Science Foundation. Each funding cycle is one year, and here we present some of the results of the ending Bro-year, including:

Engineering work

Here are some highlights of the engineering related achievements in the last year:
  • We developed a novel network control framework that provides Bro with a flexible, unified interface for active response, hiding
    the complexity of controlling heterogeneous network equipment behind a simple task-oriented API.
  • We finished and released the first version of Broker, Bro's new communication layer.
  • We finalized Bro's new plugin infrastructure that allows users and developers to more easily extend Bro with externally maintained functionality, loaded dynamically into Bro at startup in the form of shared libraries.
  • We added new protocol and file analyzers to Bro, implementing support for MySQL, Kerberos, RDP, PE, and SIP. We also overhauled the SSH analyzer, which is now extracting substantially more information, facilitating in particular a new detector that can reliably tell if an SSH login attempt was indeed authenticated successfully.
  • We substantially improved Bro's file analysis capabilities, adding (1) support for reassembly of files transferred in chunks, and potentially across independent connections; and (2) redoing the way Bro identifies file formats.
  • We substantially extended Bro's SSL/TLS/X.509 support,
    • Raising alerts for SSL connections that use old protocol
      versions, unsafe cipher suites, or weak keys.
    • Full support for record defragmentation.
    • Detection of SSL session resumption.
    • Many robustness improvements.
  • We rewrote the primary tool for analyzing Bro's ASCII logs,
    bro-cut, in C (from previously awk), improving its performance by
    an order of magnitude.
  • We improved and extended Bro's regression test-suite.
In addition to these larger efforts, we again carried out an extensive set of smaller improvements, fixes, and polishing across the whole code base. The NEWS file has a summary of what went into 2.4.

Bro Community Work

We worked with 14 institutions over the last year, providing different levels of support to help them start or imrpove their Bro setup. The main event was BroCon, our traditional 2.5 day annual conference for Bro users, located this year at MIT in Cambridge, MA. See Meet-ups section for more details.

We also hosted a smaller 1.5-day workshop, Bro4Pros, in San Francisco that we aimed specifically at advanced Bro users. The agenda is online. The workshop was hosted and sponsored by OpenDNS, which provided free facilities, catering, and publicity for the event.

We also provided a half-day Bro training workshop at the 2015 NSF Cybersecurity Summit for Cyberinfrastructure and Large Facilities. Again, please refer to the meet-ups section for more details.

As a side project, we continued deploying Bro as a distributed data collector for research purposes via the "ICSI SSL Notary" , which helps clients to identify malicious TLS certificates by providing a third-party perspective on what they should expect to receive from a server. The Notary has been operating for more than 3 years now, with now more than 3 million unique certificates (and other TLS features) extracted from more than 129 billion connections.

Bro Training

We continued and extended our efforts for training people on Bro. This included:
  • We advanced our live training environment, formerly called
    BroLive!, into the more general educational platform ISLET, an
    "Isolated, Scalable, & Lightweight Environment for Training".
  • Our web-based sandbox for executing Bro scripts,, has been improved. Among other work, try.bro now allows for more
    detailed log inspection, and it provides the ability to run all
    Bro versions since 1.5 for comparing their specifics and
  • We added more videos to your YouTube channel continued to
    adjust our training material according to the needs of the community.
  • The first Bro challenge was presented at BroCon'15. We will continue the work on this topic.

Bro Meet-ups

BroCon'15 Celebrated 20 Years of Bro!

180 people joined us for 2.5 days of talks and demos at MIT, celebrating 20 years of Bro. Vern Paxson gave the keynote speech, summarizing the last 20 years of Bro, recalling its history. We had a great set of talk and demos this year which are finally available as videos on Youtube.

The exercise sessions were replaced by do-it-yourself exercises and a challenge. Keith Lehigh won the challenge. Thank you Keith. The challenge can be found here.

We hear you: Our survey this year told us that more than 90% liked the topics and their presentations (2 and 3 on the 0 to 3 scale), although some people are hoping for the training sessions to return in the future. Overall, we appreciate the very positive feedback we received, and promise to keep the opportunities for improvement in mind as we begin planing for BroCon 2016.

NSF Cybersecurity Summit 2015

Bro held a one day workshop at the NSF Cybersecurity Summit 2015.

Bro Commits: Bro 2.4.1 is here!

Bro 2.4.1 has been released. This release addresses a few potential DOS vectors using specially crafted connections. The release also contains minor updates to analyzers to reduce the number of messages in reporter.log. The source distribution is available on the download page. Users should be able to automatically update the package using their system package manager. See CHANGES for the full list of changes in the release. Since this is only a bug fix release, we encourage users to update at their earliest convenience.

Bro Internals: Bro has joined Software Freedom Conservancy

The Bro Project is excited to announce it has joined Software Freedom Conservancy (SFC), a non-profit organization that promotes and protects open source projects. To learn more about this decision, see our blog post.

Tuesday, October 6, 2015

Bro & Software Freedom Conservancy

The Bro Project is excited to announce it has joined Software Freedom Conservancy (SFC).

SFC is a not-for-profit organization that helps promote, improve, develop, and defend Free, Libre, and Open Source Software (FLOSS) projects. You are likely familiar with many of its member projects; including Git, BusyBox, Samba, and PyPy.

We chose to join a foundation for several reasons: it builds community transparency and trust, provides legal protection for contributors, clarifies intellectual property, and signifies longevity for the project. SFC provides all of these. They leave the technical and artistic control of the project to the contributors and community.

Membership with SFC includes forming a leadership team. Members of the leadership team are:
  • Seth Hall, International Computer Science Institute
  • Keith Lehigh, Indiana University
  • Vern Paxson, University of California at Berkeley
  • Michal Purzynski, Mozilla Foundation
  • Aashish Sharma, Lawrence Berkeley Lab
  • Adam Slagell, National Center for Supercomputing Applications
  • Robin Sommer, International Computer Science Institute

Financial contributions to the Bro Project will now be managed by SFC. We added a donate page and PayPal button to our site. The page includes instructions for alternate payment options (check or wire transfer) if you do not wish to use a credit card.

If you use Bro and would like to give back to the Project, please consider donating.

We thank SFC and the Bro community for its continued support.

Thursday, September 10, 2015

Analyzing Bro Logs with Sagan


Applying log analysis tools to Bro logs can improve event correlation and expedite the use of pattern based signatures for quick detection. Sagan, a multithreaded log analysis engine written by Champ Clark "Da Beave" is a good candidate for performing log analysis on Bro for at the following reasons:

  • Sagan supports the Bro intel file format through a preprocessor
  • Contains existing rules for detections from Bro logs
  • Uses the familiar snort-like rule language
  • Ability to output data in unified2, integrates with existing tools like Snorby, Sguil, Squert, etc.
OSSEC is another popular tool that can perform log analysis and is able to integrate with other tools.


To implement this Bro logs can be forwarded to a system running Sagan via a syslog daemon that supports forwarding on the Bro manager. There is also a syslog daemon listening on the Sagan host which accepts the Bro logs and writes them to a FIFO (named pipe) from which sagan reads. For each log sagan reads it will create a worker thread to perform analysis by applying its rules to the logs. See the documentation for details on installing and configuring Sagan. A few examples are given below for forwarding Bro logs to a remote syslog host where Sagan lives.

A forwarding example with Rsyslog (rainer-script):
module(load="imfile" PollingInterval="1")

# Read in dns.log on Bro manager

# Forward logs to sagan system
A forwarding example using the older Rsyslog syntax:
$ModLoad imfile

# Read in dns.log on Bro manager
$InputFileName /usr/local/bro/logs/current/dns.log
$InputFileTag bro_dns:
$InputFileStateFile stat-bro_dns
$InputFileSeverity debug
$InputFileFacility local6
Use multiple input configurations to send more Bro logs.


Sagan has a rules package that includes existing snort-like rules for bro logs, this file is named bro-ids.rules. Below are a few custom rules written by Jon Schipp which were presented at BroCon'15.

The first rule detects hosts which made at least 10 DNS requests in an hour (3600s) for names that are present in an intelligence feed. For this to work Sagan's Bro Intel preprocessor needs to be enabled and pointing to Bro formatted intel files in sagan.conf.
# sagan.conf
processor bro-intel: /usr/local/etc/,/usr/local/etc/,/usr/local/etc/
# Include custom bro rules
include $RULE_PATH/local-bro.rules
The magic of the rule is done with the bro-intel: domain option which matches all feed entries with type Intel::DOMAIN across the logs Sagan is analyzing.

# local-bro.rules
alert udp $EXTERNAL_NET any -> $HOME_NET $DNS_PORT (msg: "[BRO] Excessive Bad Domains (10+)"; bro-intel: domain; after: track by_src, count 10, seconds 3600; parse_src_ip: 1; parse_dst_ip: 2; classtype: suspicious-traffic; sid: 13000000;rev:1;)
Another example is a more advanced detection that works across multiple rules using flowbits, a feature of the snort-like rule language. Doing this we can perform basic correlation across different logs files such as checking for an HTTP request in http.log and then looking for a file that was carried across the connection in files.log. A practical example of this is to test for the successful use of a proxy by matching a HTTP request that is indicative of proxy behavior and then checking files.log after for a transferred file of a guessable significant size within 60 seconds of the original HTTP request. Having arithmetic operators like less than or greater than would be helpful in expressions where we want to compare byte counts but there are problems

  1. Expressions like these are not available in this rule language
  2. This language doesn't understand Bro fields (e.g. files.log has multiple fields of type count)

For example, because of current conditions we cannot tell Sagan to match on files.log where the value of the seen_bytes field is greater than say 1024 because arithmetic operators are not available, and even if they were Sagan wouldn't know which field to use to evaluate the expression (it could compare it to an IP address which contains numbers because it doesn't have the concept of data types). Though with some ingenuity and luck we can make due with a detection like this. There's a field in files.log called duration with a unique type of interval which looks similar to a floating point number. We can do a match on the decimal point and some digits that would indicate that the file took longer to transfer than x seconds. I chose 0.00 as the value to perform a negation match on i.e. the rule will only match if 0.00 is not present in the log line e.g. a duration of 1.24 will trigger an alert. This is a best guess indicator that the file transferred over the HTTP connection was large enough to take more than 0 seconds. Note that it does not take account of network conditions which makes it imperfect like most of the rules we have today.

The first rule matches on the HTTP CONNECT method commonly used by clients accessing a proxy. It does not alert due to its use of the noalert options. Its purpose is to trigger an event via a flowbit once a proxy attempt using CONNECT occurs, when this happens the next rule which is watching for the flowbit named bro_possible_proxy_connect will be called.
# Match on HTTP CONNECT methods
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORT (msg: "[BRO] Possible Proxyvia CONNECT"; content: " CONNECT "; content: "ROXY-CONNECTION"; parse_src_ip: 1; parse_dst_ip: 2; flowbits: set, bro_possible_proxy_connect, 60; flowbits: noalert; classtype: suspicious-traffic; sid: 11000002; rev:1;)
The second rule is called to match on files.log, it uses a few content matches to identify the log by its content such as containing hashes of files e.g. SHA. The parse ip instructions are used to noramalize the direction of the IP addresses used in the original HTTP request which will be in reverse given that the files will most likely becoming from the server. This is needed to provide correlation by tracking the offender IP across the HTTP request and transferred file, we don't want to alert from a transfer indicated in files.log by some other host which never made the HTTP CONNECT method!
# Follow up rule to validate the use of a proxy
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORT (msg: "[BRO] Proxy Detectedvia CONNECT"; content: "SHA"; content:!"0.00"; pcre: "/SSL|HTTP|FTP/"; parse_src_ip: 2; parse_dst_ip: 1; flowbits: isset,by_src,bro_possible_proxy_connect;
classtype: suspicious-traffic; sid: 11000004; rev:1;)
Syslog tags can be used in rules to identify different log files. There's plenty more to detect and explore - if you're performing log analysis on Bro share your rules and experiences with the community.


For more information see the Bro Integrations slides and talk at BroCon '15

Tuesday, September 8, 2015

Bro 2.4.1 Release

Bro 2.4.1 has been released. This release addresses a few potential DOS vectors using specially crafted connections. The release also contains minor updates to analyzers to reduce the number of messages in reporter.log. The source distribution is available on the download page. Our binary packages will be updated later today - users should be able to automatically update the package using their system package manager.

See CHANGES for the full list of changes in the release.

Since this is a bug fix release, we encourage users to update at their earliest convenience.

The Bro Team

Tuesday, June 16, 2015

OpenSSL Denial of Service Impacting Bro - CVE-2015-1788

A denial of service exploit for OpenSSL was announced recently.  We verified that the vulnerability does propagate into Bro and has the same affect in Bro as in other software that uses OpenSSL.  If a Bro process sees a certificate that is mangled in the way described in the announcement it will pass the certificate to OpenSSL and it causes the Bro process to lock up and have high CPU utilization.

Everyone is going to want to upgrade OpenSSL on their Bro devices as soon as possible.  This is easy to exploit since X.509 certificate parsing happens in a number of places in Bro and a usable proof of concept certificate was released with the announcement.

In the event that you are unable to upgrade OpenSSL on your installation immediately, we have a script that can be used to disable X509 certificate handling on Bro.  It is a stopgap measure and should only be used temporarily due to the fact that any analysis being performed that relied on certificate parsing will be broken.  It will make your installation avoid the DoS though.

The short and simple script can be downloaded here:

Good luck, and reach out to us on the Bro mailing list if you have any trouble.

Update #1. RedHat has pointed out that their distributions and derivatives don't have this problem because of their compile options.  The RedHat notification:

Update #2.  The script to compensate for the problem has been updated and should now support 2.3 as well as 2.4 (including the brief file api that existed during the development cycle but was changed before the release).  We've only validated the problem on 2.3 and 2.4 and generally recommend that everyone runs nothing older than those two release series as a general rule.