From vern at ee.lbl.gov  Sun Oct  4 00:52:04 1998
From: vern at ee.lbl.gov (Vern Paxson)
Date: Sun, 04 Oct 1998 00:52:04 PDT
Subject: bro 0.5 alpha now available
Message-ID: <199810040752.AAA00141@daffy.ee.lbl.gov>

The Bro 0.5 alpha distribution is now available from

	ftp://ftp.ee.lbl.gov/.vp-bro-0.5-alpha.tar.gz

The main changes are Linux support and better portability via reworked
autoconf'ing, both thanks to Craig Leres.

		Vern


From deniman at Colorado.EDU  Sun Oct 11 17:57:05 1998
From: deniman at Colorado.EDU (Dave Deniman)
Date: Sun, 11 Oct 1998 18:57:05 -0600 (MDT)
Subject: file format
Message-ID: <Pine.GSO.3.96.981011182531.16560A-100000@ucsub.Colorado.EDU>

We are a senior project group from the University of Colorado at Boulder.
We are beginning research into intrusion detection and are considering
using Bro. After browsing the source code, we have questions:

- is there an archive for this mailing list?
- is there more documentation or any faqs specifically for Bro?
- is a signature data file utilized? If so, what module(s) access it?
- are there some example log files available?

We are currently waiting for the hardware to install Bro, but are trying
to determine the formats of the signature file and log files for design
purposes.  

Any assistance would be greatly appreciated.

Thanks,
Dave, Kelly, Jason, Mike, Paul



From tarkhil at sl.ru  Sun Oct 11 23:47:47 1998
From: tarkhil at sl.ru (Alexander B. Povolotsky)
Date: Mon, 12 Oct 1998 10:47:47 +0400
Subject: file format 
In-Reply-To: Your message "Sun, 11 Oct 1998 18:57:05 MDT."
             <Pine.GSO.3.96.981011182531.16560A-100000@ucsub.Colorado.EDU> 
Message-ID: <199810120647.KAA05726@enterprise.sl.ru>

 <Pine.GSO.3.96.981011182531.16560A-100000 at ucsub.Colorado.EDU>Dave Deniman writ
es:
>- is there more documentation or any faqs specifically for Bro?
No. I'm going to do something, but first I have to understand Bro without any 
docs :-(


Alex.



From vern at ee.lbl.gov  Sun Oct 11 23:50:17 1998
From: vern at ee.lbl.gov (Vern Paxson)
Date: Sun, 11 Oct 1998 23:50:17 PDT
Subject: file format
In-Reply-To: Your message of Sun, 11 Oct 1998 18:57:05 PDT.
Message-ID: <199810120650.XAA29930@daffy.ee.lbl.gov>

> - is there an archive for this mailing list?

Yes.  To get a list of past messages, send a message to bro-request at lbl.gov
with the subject "archive ls latest".  To then retrieve a message, use
"archive get latest/<number>" for a message with the given number, or
"archive get latest/<number>*" for those messages that match the pattern
<number>* (so "archive get latest/*" retrieves all of the messages).
Unfortunately, when using a pattern each message matching the pattern is
returned in a separate message, which is a bit clunky.

> - is there more documentation or any faqs specifically for Bro?

No, just what's distributed in the doc/ directory.  This is a major hole.

> - is a signature data file utilized? If so, what module(s) access it?

When you run Bro, you give it as an argument the policy file(s) to load.
The usual one you use is "mt", which corresponds to pub-policy/mt.bro.
It then @load's a bunch of other policy files, which are also found
in pub-policy.

> - are there some example log files available?

See doc/conn-logs for a description of the connection summaries generated
by tcp.bro (I assume this is what you're asking about).

> We are currently waiting for the hardware to install Bro, but are trying
> to determine the formats of the signature file and log files for design
> purposes.  

Bro doesn't have signature files per se.  It instead has a language for
expressing event handlers.  One common thing to do with these is express
signatures.  It's also the policy files that write whatever logs you want
them to write.  The default logs written are those produced by tcp.bro,
ftp.bro, and finger.bro.  The language is informally described in the USENIX
paper, and meant to be fairly clear upon study of the policies distributed
in pub-policy/.

		Vern


From vern at ee.lbl.gov  Mon Oct 12 11:55:13 1998
From: vern at ee.lbl.gov (Vern Paxson)
Date: Mon, 12 Oct 1998 11:55:13 PDT
Subject: accessing the Bro mailing list archives
Message-ID: <199810121855.LAA01303@daffy.ee.lbl.gov>

Doing so is described in

	http://www.lbl.gov/icsd/cms/email/mail-lists-archives.html

and this is now part of the welcome message new subscribers receive.

		Vern


From sthaug at nethelp.no  Wed Oct 14 15:23:28 1998
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Thu, 15 Oct 1998 00:23:28 +0200
Subject: How to control when bro logs events
Message-ID: <22350.908403808@verdi.nethelp.no>

I've just started to investigate bro here. I'd like to use it for real
time network monitoring, and an obvious (to me) question is: How quickly
is an event (say, a TCP session finishing the normal way) logged? How can
I control this?

I assume I might have to turn off stdio buffering to be able to see such
events right away. Are there other knobs to adjust?

Steinar Haug, Nethelp consulting, sthaug at nethelp.no


From vern at ee.lbl.gov  Wed Oct 14 20:20:29 1998
From: vern at ee.lbl.gov (Vern Paxson)
Date: Wed, 14 Oct 1998 20:20:29 PDT
Subject: How to control when bro logs events
In-Reply-To: Your message of Thu, 15 Oct 1998 00:23:28 PDT.
Message-ID: <199810150320.UAA15137@daffy.ee.lbl.gov>

> How quickly
> is an event (say, a TCP session finishing the normal way) logged? How can
> I control this?

Logging occurs whenever your policy script executes a "log" statement,
and it goes out immediately via syslog().  If you're printing using
"print" to a file, then it's block buffered.  Adding a flush mechanism
is on the to-do list.

Bro generally strives to generate events as soon as it can, so the policy
script immediately gets a crack at them (and can promptly log if need be).
connection_established is generated when the SYN ack is seen (Bro doesn't
wait for the final ack completing the three-way handshake, because often it
won't ever see it because of use of a SYN/FIN/RST filter).  Likewise,
connection_rejected is generated as soon as the RST is seen.  However,
connection_attempt is only generated five minutes after the first SYN
is seen, to give the connection time to first become established.
Bro could generate this sooner, or make it tunable, or generate a
connection_first_packet event on the first packet (if the policy
script includes a handler).  I'd be interested in hearing from folks
who find they'd like that - it's an easy addition.

		Vern