I am integrating bro into a larger system so that I can use it to keep track
of connections (which seems easier than trying to write a method from
scratch with pcap). I thought it would be straightforward to grep for print
or email or alarm statements to figure out where to put the hooks for an IPC
message but so far it eludes me. Is there a principal module for outputting
I have bro version bro-0.9a9 running. I see files in /usr/local/bro/logs correctly, but the reports are empty.
The other problem is the /usr/local/bro/archive direttory is empty too.
What can I do to generate the correctly reports?
I tested with one and two interfaces (etho and eth1), I'm using Red Hat Enterprise ES 3.
I saw the traffice using tcpdump.
I was wondering what the semantics of &write_expire are for sets. For
example, in trw.bro I see
global scan_sources: set[addr] &write_expire = 1 day;
The CHANGES file says that a *table* entry will be deleted if an entry
isn't written to within the specified timeframe. Sets obviously don't
have anything that can be written to other than the keys themselves, so
for sets, I presume write_expire means that an entry has to be re-
entered within the timeframe to avoid deletion?
In the logs directory /usr/local/bro/logs, I have logs about my scan tests and real traffic, but if I run the site-report.pl and mail_reports.sh scripts, they don't show
the scans and incidents.
What the best form to resolve this? The report shows somes local IPs, but it doesn't show the scans or incidents details. And if I generate other reports with new logs the report was the same :(
I'm forwarding this from the tcpdump-workers list since it's of interest
to various folks around here.
-------- Forwarded Message --------
> From: Gianluca Varenni <gianluca.varenni(a)gmail.com>
> Reply-To: tcpdump-workers(a)lists.tcpdump.org
> To: winpcap-users(a)winpcap.org, tcpdump-workers(a)lists.tcpdump.org,
> Ethereal development <ethereal-dev(a)ethereal.com>
> Subject: [tcpdump-workers] [ANNOUNCE] NTAR - PCAP next generation dump
> file format implementation
> Date: Sat, 25 Jun 2005 17:15:34 -0700
> Hi all.
> This mail is to announce the birth of the NTAR project. NTAR stands for
> Network Trace Archival and Retrieval library, and is an implementation of
> the PCAP next generation dump file format, that was proposed and discussed
> last year by several folks on the libpcap/tcpdump and WinPcap mailing lists.
> The library is released under the 3-clause/BSD license.
> The URL of the project is:
> On this website you can find
> - the source file of the library (both for windows and *nix)
> - the HTML documentation of the API (generated with doxygen from the
> commented source files), both for the user and for someone wanting to
> extend it. The docs contain some tests/examples that you can look to
> get an idea of how the library works.
> - An updated version of the PCAP draft specifying the file format.
> The original draft of the file format is available at
> I'm seeking contributors to improve the library in terms of
> - testing the library on different platforms and operating systems
> - reviewing the API
> - implementing new extensions to the library.
> A mailing list, ntar-workers(a)winpcap.org, has been created for NTAR-related
> discussions. People interested in this project are welcome to join it, the
> mailman web interface to subscribe is available at
> Have a nice day
> Gianluca Varenni
> /tmp/bro/bro/policy/pcap.bro, line 62: error: unknown identifier log, at
> or near "log"
What version of Bro are you using? 0.9 has changed "log" to "alarm". In
addition, pcap.bro that ships with the latest 0.9 doesn't have a line like
the one you show.
I've been tinkering with getting bro running on a Linksys commodity
router which has a MIPS processor & runs linux.
bro has been compiled for MIPS & transferred to the linksys. The folks
at www.openwrt.org have made up quite a nice distribution. It actually
is a nice general purpose (albeit tiny) Linux box. The tmp directory is
in ram, the rest is actually in flash memory in compressed form, and is
read-write, so you actually have a persistant file system (although, of
course, flash has a limited number of re-write cycles, so you wouldn't
want to abuse that property). It makes it nice for installing custom
Anyway, bro gets this error when starting up:
/tmp/bro/bro/policy/pcap.bro, line 62: error: unknown identifier log, at
or near "log"
---- Here's where it fails:
if ( ! install_pcap_filter(DefaultPcapFilter) )
log fmt("%.6f Can't install default pcap filter
(cmdline override?)", network_time());
which sort of indicates to me that somehow the lexical analysis code is
incomplete, and 'log' is not being identified as a keyword.
Incident Response Manager
Computer Protection Program
Lawrence Berkeley National Laboratory
Your fortune for today is:
"I've seen, I SAY, I've seen better heads on a mug of beer"
-- Senator Claghorn
Ah - I see the problem. I misinterpreted:
> >> However, when I start bro I get error: can't open drop.
to mean it was coming from the shell. But it's coming from Bro. There
isn't any policy script called drop.bro, so it's telling you that "@load
You turn on address dropping by
redef can_drop_connectivity = T;
and redefining "drop_connectivity_script" (which it sounds like you've
> I am trying to get bro (9a8) to capture http events that are not coming
> over port 80/tcp as well as several other ports.
The only way to do this currently is to modify Sessions.cc to add the other
ports of interest (search on "80" to see where the additions are needed).
You'll also need to change the capture filter in http-request.bro (or make
your own version that adds the port to capture_filters - that's cleaner).
> "not tcp dst port 80 and not tcp dst port 8080"
> However, bro seems to be only reading one filter and not the second part
> of filter.
This is strange - Sessions.cc already treats 8080 (and 8000 and 3128) the
same as 80. Can you provide a trace that exhibits the problem?
I've finally had a chance to look into this - sorry about the delay. I had
misinterpreted your original comment - I thought you were asking about
detecting ACK scanning, not flooding. Bro doesn't have a flood-detection
script other than for SYN flooding (which is in synflood.bro), so it's
expected that it wouldn't detect this. (FYI, I have a tweak to it for
detecting ACK scanning, but this is tricky because it's hard to distinguish
between ACK scanning and SYN flooding backscatter.)
> The attachment is a small trace file. thanks
FYI, the trace has numerous checksum errors (confirmed by tcpdump) -
something to be aware of when analyzing it.