./configure --with-openssl=/usr/local/opt/openssl

• A lot of this topic is covered within load balancing.
• The NSMWiki has a page on Collecting Data for different OSes.

Two older papers on packet capture with commodity hardware of the time. The hardware may be outdated. The methods may still be helpful.

• An IMC 2010 paper by Lothar Braun et al. evaluates packet capture performance on commodity hardware
• Fabian Schneider’s research on Packet Capture in 10-Gigabit Ethernet Environments Using Contemporary Commodity Hardware

• Dropped packets reported by the capture library, example:

PacketFilter::Dropped_Packets 2 packets dropped after filtering,
17392297 received, 17392295 on link

• Capture loss reported by the TCP analyzer, example:

CaptureLoss::Too_Much_Loss  The capture loss script detected an
estimated loss rate above 10.476%

Dropped packets will cause both locations to report loss, but capture loss can be caused by an issue upstream from Zeek and can be reported without any dropped packets.
The first step in troubleshooting loss is to determine if you are having an upstream problem or a local problem. Look at the values reported for Dropped_Packets as well as CaptureLoss. Your system will have one of two conditions:

• Capture loss with dropped packets
• Capture loss without dropped packets

• Run multiple workers on a single server using load balancing
• If you are running multiple workers, make sure CPU affinity is properly configured
• Temporarily disable any locally written scripts that might be causing performance problems

• An upstream device is dropping packets
• The Ethernet interface on the Zeek worker is improperly configured

It is common for an upstream device to drop packets when using SPAN ports instead of dedicated passive taps.
If the Ethernet interface on a Zeek worker is not properly configured Zeek may be unable to capture an entire IP packet. Some NICs offload the reassembly of traffic into “superpackets” so that fewer packets are passed up the stack (e.g. “TCP segmentation offload”, or “generic segmentation offload”). This causes the capturing application to observe packets much larger than the MTU of the interface from which they were captured, and may interfere with the maximum packet capture length, or snaplen. Therefore it’s a good idea to disable an interface’s offloading features.
You can use the ethtool program on Linux to view and disable offloading features of an interface. See this page for more explicit directions:
http://securityonion.blogspot.com/2011/10/when-is-full-packet-capture-not-full.html

pkg_add bro

In addition to installing Zeek, this will also automatically install all packages required by Zeek. After installing Zeek, the configuration files will be in the /etc/bro directory.

pkg_add cmake bison swig libbind bash python findutils

If the pkg_add command prompts you to choose a python version, then the recommended version is 2.7.
Geolocation of IP addresses can optionally be added to Zeek by installing these packages:

pkg_add GeoIP geolite-city

Before attempting to build Zeek, make sure to set the following environment variable:

export LDFLAGS="-L/usr/local/lib/libbind -lbind -Wl,-rpath /usr/local/lib/libbind"
Generally, please note that we do not regularly test OpenBSD builds. We appreciate any patches that improve Zeek’s support for this platform.

git pull
git submodule update --recursive --init

Then, you’ll need to rebuild Zeek. Before doing “make install” you need to first stop all running Zeek instances (if using BroControl, this is accomplished with a “broctl stop”).

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

Alternatively, you can add something like this to one of your local Zeek scripts:

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 Zeek 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 Zeek, 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 (not 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 given here 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, but there are a lot of dragons when you stray from that path.

sudo setcap cap_net_raw,cap_net_admin=eip /path/to/bro

Now any unprivileged user should have the capability to capture packets using Zeek provided that they have the traditional file permissions to read/execute the bro binary.

• Example of manually changing BPF device permissions to allow users in the admin group to capture packets:

sudo chgrp admin /dev/bpf*
sudo chmod g+r /dev/bpf*

• Example of configuring devfs to set permissions of BPF devices, adding entries to /etc/devfs.conf to grant admin group permission to capture packets:

sudo sh -c 'echo "own    bpf    root:admin" >> /etc/devfs.conf'
sudo sh -c 'echo "perm   bpf    0640" >> /etc/devfs.conf'
sudo service devfs restart

1. The -C command line option to bro.

2. An option called ignore_checksums that can be redefined at the policy script layer (e.g. in your $PREFIX/share/bro/site/local.bro):

   redef ignore_checksums = T;
   

3. An alternative is to disable checksum offloading for your network adapter, but this is not always possible or desirable. Disable checksum offloading on the NIC using ethtool --offload <int> rx off tx off so the correct checksums are generated to begin with. Replacing <int> with the name of your interface.

There are a number of software packages that include or work with Zeek. See our list of related software for more information. For support, contact the corresponding developer.

The short answer is “it depends”.
In general, if Zeek sees a packet you can write an analyzer for it. Yes, Zeek is that flexible.
The longer answer: It really depends. On what you want to analyze, on the skill level, your knowldge of the network stack, the protocol, Zeek, C++, Zeek scripting, and more.

• Every protocol above the transport layer is relatively easy to analyze. Zeek offers a tool that supports writing analyzers, called BinPac. There is a BinPac tutorial to help you create an analyzer.
• BinPac cannot be used for protocol analyzers on the layers below application layer. Especially for layer two this task is difficult. A starting point could be our ARP analyzer.