From rmkml at wanadoo.fr  Wed Dec  1 08:19:01 2004
From: rmkml at wanadoo.fr (rmkml)
Date: Wed, 1 Dec 2004 17:19:01 +0100 (CET)
Subject: [Bro] Check tcp sequence number ?
In-Reply-To: <1101865451.28110.192.camel@localhost>
References: <Pine.LNX.4.61.0411300744390.1130@hp.>  <1101833796.28108.132.camel@localhost>
  <Pine.LNX.4.61.0411302154540.1606@hp.> <1101865451.28110.192.camel@localhost>
Message-ID: <Pine.LNX.4.61.0412011630460.1141@hp.>

Hi,

Thx for reply Christian,


First test with www.bro-ids.org : (join pcap1 file)

Injection packet is n? 4.

Bro09a7 not event ...


another test on www.snort.org (this web not ack, pcap2 file)

Injection packet is n? 4.

Bro09a7 not event ...


Regards

Rmkml at Wanadoo.fr


PS: Strange, bro web on first test, not Ack, but after snort test, web bro 
Ack !


On Wed, 1 Dec 2004, Christian Kreibich wrote:

> Date: Wed, 01 Dec 2004 01:44:12 +0000
> From: Christian Kreibich <christian at whoop.org>
> To: Bro List <bro at bro-ids.org>
> Subject: Re: [Bro] Check tcp sequence number ?
> 
> On Tue, 2004-11-30 at 21:00, rmkml wrote:
>> yes,
>> but explain my pb :
>>   $ telnet xxx
>>   $ hping2 send Push on tcp open telnet to xxx
>>   my xxx Ack, but Push sequence number is bad
>
> You mean intentionally bad (i.e., you set it to some garbage value), I
> presume.
>
>>   bro (snort/prelude/firestorm) not event this ...
>> Strange ?
>
> No -- there are precise semantics in TCP regarding what sequence numbers
> are acceptable at a given time, so anything outside of the acceptable
> window is just ignored. There's no danger of confusion here between the
> IDS and the end host, so it's not worth reporting.
>
> Note that Bro *does* report content gaps though.
>
> Regards,
> Christian.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pbseqnum1.tcpdump.bz2
Type: application/octet-stream
Size: 23184 bytes
Desc: 
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20041201/5b21401c/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pbseqnum2.tcpdump.bz2
Type: application/octet-stream
Size: 997 bytes
Desc: 
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20041201/5b21401c/attachment-0001.obj 

From christian at whoop.org  Fri Dec  3 06:27:24 2004
From: christian at whoop.org (Christian Kreibich)
Date: Fri, 03 Dec 2004 14:27:24 +0000
Subject: [Bro] About IDs in MutableVals
Message-ID: <1102084044.28111.384.camel@localhost>

Hi,

I don't quite understand the purpose of the 'id' member in MutableVals
and I was hoping someone could explain it to me, particularly what the
unique ID stuff is all about. In Val.h I read

  // Each MutableVal gets a globally unique ID that can be used to
  // reference it no matter if it's directly bound to any user-visible
  // ID. This ID is inserted into the global namespace.

Why is this global namespacing done?

Thanks!
Christian.
-- 
________________________________________________________________________
                                          http://www.cl.cam.ac.uk/~cpk25
                                                    http://www.whoop.org




From sommer at in.tum.de  Fri Dec  3 07:16:38 2004
From: sommer at in.tum.de (Robin Sommer)
Date: Fri, 3 Dec 2004 16:16:38 +0100
Subject: [Bro] About IDs in MutableVals
In-Reply-To: <1102084044.28111.384.camel@localhost>
References: <1102084044.28111.384.camel@localhost>
Message-ID: <20041203151638.GA27236@net.informatik.tu-muenchen.de>

On Fri, Dec 03, 2004 at 14:27 +0000, Christian Kreibich wrote:

> Why is this global namespacing done?

It's for synchronizing values across multiple Bro's.

Let's say we have a table of type "table[count] of some_record". If
two Bros are synchronizing this table across them, they are supposed
to always see the same table content. In particular, if Bro A
modifies a field of some of the records, the change has to appear in
the table of Bro B. That means that Bro A has to propagate the
information "change field x of this record" to Bro B. But for this,
we need a name for "this record" on which both sides agree. That's
where the global namespace is needed. You can see these names as
something like pointers which are globally valid. (In this simple
case, we could have used the table's index as the record's name, but
that doesn't work anymore if aliasing is involved; e.g., the same
record instance is contained in more than one table).

Hope this helps,

Robin

-- 
Robin Sommer * Room        01.08.055 * www.net.in.tum.de
TU Muenchen  * Phone (089) 289-18006 *  sommer at in.tum.de 


From christian at whoop.org  Fri Dec  3 07:49:15 2004
From: christian at whoop.org (Christian Kreibich)
Date: Fri, 03 Dec 2004 15:49:15 +0000
Subject: [Bro] About IDs in MutableVals
In-Reply-To: <20041203151638.GA27236@net.informatik.tu-muenchen.de>
References: <1102084044.28111.384.camel@localhost>
	 <20041203151638.GA27236@net.informatik.tu-muenchen.de>
Message-ID: <1102088954.28106.400.camel@localhost>

On Fri, 2004-12-03 at 15:16, Robin Sommer wrote:
> On Fri, Dec 03, 2004 at 14:27 +0000, Christian Kreibich wrote:
> 
> > Why is this global namespacing done?
> 
> It's for synchronizing values across multiple Bro's.

Ah!

> Let's say we have a table of type "table[count] of some_record". If
> two Bros are synchronizing this table across them, they are supposed
> to always see the same table content. In particular, if Bro A
> modifies a field of some of the records, the change has to appear in
> the table of Bro B. That means that Bro A has to propagate the
> information "change field x of this record" to Bro B. But for this,
> we need a name for "this record" on which both sides agree. That's
> where the global namespace is needed. You can see these names as
> something like pointers which are globally valid. (In this simple
> case, we could have used the table's index as the record's name, but
> that doesn't work anymore if aliasing is involved; e.g., the same
> record instance is contained in more than one table).

Okay it's much clearer now, thanks! I guess what's still confusing me is
why is this happening at the MutableVal level and not in Vals directly?
Why does the synchronization need to be aware of the fact that the
synchronized val happens to be sitting in some kind of MutableVal?

I think this also comes back to the properties in MutableVals that I
don't quite understand -- why are these not attributes?

Thanks again, and sorry for the bombardment -- it's the subtleties I'm
coming across trying to get records to work in Broccoli ... I can
receive them but right now I'm mass-murdering Bros whenever I send them
:)

Cheers,
Christian.
-- 
________________________________________________________________________
                                          http://www.cl.cam.ac.uk/~cpk25
                                                    http://www.whoop.org




From sommer at in.tum.de  Fri Dec  3 09:22:04 2004
From: sommer at in.tum.de (Robin Sommer)
Date: Fri, 3 Dec 2004 18:22:04 +0100
Subject: [Bro] About IDs in MutableVals
In-Reply-To: <1102088954.28106.400.camel@localhost>
References: <1102084044.28111.384.camel@localhost> <20041203151638.GA27236@net.informatik.tu-muenchen.de> <1102088954.28106.400.camel@localhost>
Message-ID: <20041203172204.GC23882@net.informatik.tu-muenchen.de>

On Fri, Dec 03, 2004 at 15:49 +0000, Christian Kreibich wrote:

> Okay it's much clearer now, thanks! I guess what's still confusing me is
> why is this happening at the MutableVal level and not in Vals directly?

Basically it's just an optimization. We could just as well assign
global names to all values -- but we don't need to. A global name is
only required when a Val can actually be changed. If it can't, it
will never be referenced by one of the operations transfered during
synchronization (for example, an assignment to an integer always
creates a new Val and destroys the old one).

Optimizing even further, we need only assign global names to MutableVals
which are actually synchronized (or, in the future, persistent).

> I think this also comes back to the properties in MutableVals that I
> don't quite understand -- why are these not attributes?

Which kind of attributes are you refering to? (The term "attribute"
is quite is overloaded in Bro...). The attributes which are
associated with Vals are RecordVals which don't really fit here
(frankly, right now I can't remember what they are for... :-). The
attributes associated with IDs are more appropiate (and, in fact,
there are ATTR_SYNCHRONIZED/ATTR_PERSISTENT for IDs). But in
general, values contained in MutableVals are not bound to any ID.
Therefore, these attributes don't help for Vals.

Does this answer your question?

> right now I'm mass-murdering Bros whenever I send them

:-)

Robin

-- 
Robin Sommer * Room        01.08.055 * www.net.in.tum.de
TU Muenchen  * Phone (089) 289-18006 *  sommer at in.tum.de 


From chema at cs.berkeley.edu  Sun Dec  5 01:04:49 2004
From: chema at cs.berkeley.edu (=?iso-8859-1?q?Jos=E9_Mar=EDa_Gonz=E1lez?=)
Date: Sun, 5 Dec 2004 01:04:49 -0800
Subject: [Bro] Mail Archive Access
Message-ID: <200412050104.49349.chema@cs.berkeley.edu>

Hi, 

Is it possible to access to the mail archives of the Bro 
list? 

I'm trying to catch up with 0.9.7, and I realized alert.bro 
doesn't exist anymore. I think I remember some mail 
about renaming alerts to something else, but I can't 
find it. 

-Chema


From jomcn at mail.com  Sun Dec  5 08:12:30 2004
From: jomcn at mail.com (john mcnicholas)
Date: Sun, 5 Dec 2004 11:12:30 -0500
Subject: [Bro] Mail Archive Access
In-Reply-To: <200412050104.49349.chema@cs.berkeley.edu>
References: <200412050104.49349.chema@cs.berkeley.edu>
Message-ID: <76FDC823-46D8-11D9-8304-000393C2FCCE@mail.com>

> Is it possible to access to the mail archives of the Bro
> list?

This link should take you to the mail archive:

http://mailman.icsi.berkeley.edu/pipermail/bro/

the link is on the mailing list page also.

> I'm trying to catch up with 0.9.7, and I realized alert.bro
> doesn't exist anymore. I think I remember some mail
> about renaming alerts to something else, but I can't
> find it.
>

The change log does a good job of describing the terminology changes.  
A link is below and it is also accessible on the download page.

However regarding your specific question, the function "ALERT()" is now 
called "NOTICE()"  (in notice.bro).

ftp://ftp.ee.lbl.gov/bro-change-log.txt


john



From christian at whoop.org  Sun Dec  5 08:22:46 2004
From: christian at whoop.org (Christian Kreibich)
Date: Sun, 05 Dec 2004 16:22:46 +0000
Subject: [Bro] Mail Archive Access
In-Reply-To: <200412050104.49349.chema@cs.berkeley.edu>
References: <200412050104.49349.chema@cs.berkeley.edu>
Message-ID: <1102263765.16326.2.camel@localhost>

On Sun, 2004-12-05 at 09:04, Jos? Mar?a Gonz?lez wrote:
> Hi, 
> 
> Is it possible to access to the mail archives of the Bro 
> list? 
> 
> I'm trying to catch up with 0.9.7, and I realized alert.bro 
> doesn't exist anymore. I think I remember some mail 
> about renaming alerts to something else, but I can't 
> find it. 

http://mailman.ICSI.Berkeley.EDU/pipermail/bro/ maybe?

Cheers,
Christian.
-- 
________________________________________________________________________
                                          http://www.cl.cam.ac.uk/~cpk25
                                                    http://www.whoop.org





From vern at icir.org  Sun Dec  5 09:02:12 2004
From: vern at icir.org (Vern Paxson)
Date: Sun, 05 Dec 2004 09:02:12 -0800
Subject: [Bro] Mail Archive Access
In-Reply-To: Your message of Sun, 05 Dec 2004 01:04:49 PST.
Message-ID: <200412051702.iB5H2CcL000574@jaguar.icir.org>

Along with what John & Christian said, note at the end of your posting:

> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro

and that last URL will take you to the list's general page, including
a link to the archives.

		Vern


From shonx001 at umn.edu  Sun Dec  5 13:22:12 2004
From: shonx001 at umn.edu (shonx001)
Date: Sun, 05 Dec 2004 15:22:12 CST
Subject: [Bro] Off-line analysis
Message-ID: <200412052122.iB5LMC3s013074@firefox.software.umn.edu>

?
When I try to off-line analysis with -r option, how can I use all Bro
rules?
I just found some example about off-line, but it seems that I can apply 1
time 1 rule.
Could you let me know how all bro rules can be applied to specific tcp
rawfile?


     # set up the Bro environment (sh or bash)
     . /usr/local/bro/etc/bro.cfg
     /usr/local/bro/bin/bro -r dumpfile backdoor.bro




From vern at icir.org  Sun Dec  5 13:38:14 2004
From: vern at icir.org (Vern Paxson)
Date: Sun, 05 Dec 2004 13:38:14 -0800
Subject: [Bro] Off-line analysis
In-Reply-To: Your message of Sun, 05 Dec 2004 15:22:12 CST.
Message-ID: <200412052138.iB5LcEl8013671@jaguar.icir.org>

> When I try to off-line analysis with -r option, how can I use all Bro
> rules?

The notion of "all Bro rules" is not that well defined.  There are a large
number (100+) of policy files in policy/*.bro, some of which are incompatible
with others (for example, print-filter.bro prints the BPF filter being used
and then exits).

That said, here's what we use when to run against our internal test suite:

	@load site
	@load mt
	@load tftp
	@load dns
	@load flag-irc
	@load smtp-relay
	@load software
	@load ssh
	@load worm
	@load backdoor.bro
	@load blaster.bro
	@load flag-warez.bro
	@load gnutella.bro
	@load http-abstract.bro
	@load http-body.bro
	@load http-reply.bro
	@load icmp.bro
	@load ssl-worm.bro
	@load stepping.bro
	@load synflood.bro

This winds up loading a whole lot of the analysis.

		Vern


From jomcn at mail.com  Sun Dec  5 14:25:14 2004
From: jomcn at mail.com (john mcnicholas)
Date: Sun, 5 Dec 2004 17:25:14 -0500
Subject: [Bro] Off-line analysis
In-Reply-To: <200412052138.iB5LcEl8013671@jaguar.icir.org>
Message-ID: <20041205222508.XGFA1463.out003.verizon.net@achilles>

> When I try to off-line analysis with -r option, how can I use all Bro
> rules?

I'm taking at stab at this since I've been wrestling with a very similar
situation for a class.  Anyway, if by rules you mean snort type signatures
you can do one of the following:

a. on the command line via -s rulefilename

b. in a policy script using the "signature_files" variable.  i'm been doing
the following:

	redef signature_files += "snort-default.sig";
	redef signature_files += "worm.sig";

In addition I threw in an event to dump some info out.

event  bro_init()
{
	print  fmt("-- signature_files = [%s]", signature_files);

	# the http_servers is readable but by no means pretty.
	print  fmt("-- http_servers = [%s]", http_servers);
}

Note: I'm no expert but I believe http_servers is signficant for a number of
the snort signatures.

For what its worth, I've been attempting to compare snort vs bro for a class
(perhaps like you are) and evidently I'm doing something wrong since I get
dozens of unique alerts (or alarms) in snort, but only 3 unique ones in bro.
I'm sure it is  a configuration problem but if anyone wants to volunteer any
suggestions it would be appreciated.

thanks.

john

	



From vern at icir.org  Sun Dec  5 14:28:35 2004
From: vern at icir.org (Vern Paxson)
Date: Sun, 05 Dec 2004 14:28:35 -0800
Subject: [Bro] Off-line analysis
In-Reply-To: Your message of Sun, 05 Dec 2004 17:25:14 EST.
Message-ID: <200412052228.iB5MSZqq016081@jaguar.icir.org>

> For what its worth, I've been attempting to compare snort vs bro for a class
> (perhaps like you are) and evidently I'm doing something wrong since I get
> dozens of unique alerts (or alarms) in snort, but only 3 unique ones in bro.
> I'm sure it is  a configuration problem but if anyone wants to volunteer any
> suggestions it would be appreciated.

Can you send me an example (perhaps off-line)?

		Vern


From shonx001 at umn.edu  Sun Dec  5 15:13:38 2004
From: shonx001 at umn.edu (shonx001)
Date: Sun, 05 Dec 2004 17:13:38 CST
Subject: [Bro] Off-line analysis
Message-ID: <200412052313.iB5NDcdZ024425@firefox.software.umn.edu>

If so, 
I first have to make "my own".bro, and then add the "my own.bro" file to
policy setting in bro.cfg?

What I'm wondering is to set up for general IDS OFF-Line test.
In my thought, it is not easy to test in Off-line in comparison with Snort,
although Bro performance is better than snort. :)

I really appreciate if you tell me know more specific method to use Bro in
off-line test.

Best Regards,
Taeshik

On 5 Dec 2004, Vern Paxson wrote:
> > When I try to off-line analysis with -r option, how can I use all Bro
> > rules?
> 
> The notion of "all Bro rules" is not that well defined.  There are a
large
> number (100+) of policy files in policy/*.bro, some of which are
incompatible
> with others (for example, print-filter.bro prints the BPF filter being
used
> and then exits).
> 
> That said, here's what we use when to run against our internal test
suite:
> 
> 	@load site
> 	@load mt
> 	@load tftp
> 	@load dns
> 	@load flag-irc
> 	@load smtp-relay
> 	@load software
> 	@load ssh
> 	@load worm
> 	@load backdoor.bro
> 	@load blaster.bro
> 	@load flag-warez.bro
> 	@load gnutella.bro
> 	@load http-abstract.bro
> 	@load http-body.bro
> 	@load http-reply.bro
> 	@load icmp.bro
> 	@load ssl-worm.bro
> 	@load stepping.bro
> 	@load synflood.bro
> 
> This winds up loading a whole lot of the analysis.
> 
> 		Vern
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
> 




From shonx001 at umn.edu  Sun Dec  5 15:39:26 2004
From: shonx001 at umn.edu (shonx001)
Date: Sun, 05 Dec 2004 17:39:26 CST
Subject: [Bro] Off-line analysis
Message-ID: <200412052339.iB5NdQkg027113@firefox.software.umn.edu>

Thanks for your kind explanation.
Anyhow, what I really want to know is to do some ID attack ananlsys using
Bro.
If you have experienced such things with Bro, please let me know.
I get some tcpdump raw file, but it is not easy to handle Bro for offline
test.

On 5 Dec 2004, john mcnicholas wrote:
> > When I try to off-line analysis with -r option, how can I use all Bro
> > rules?
> 
> I'm taking at stab at this since I've been wrestling with a very similar
> situation for a class.  Anyway, if by rules you mean snort type
signatures
> you can do one of the following:
> 
> a. on the command line via -s rulefilename
> 
> b. in a policy script using the "signature_files" variable.  i'm been
doing
> the following:
> 
> 	redef signature_files += "snort-default.sig";
> 	redef signature_files += "worm.sig";
> 
> In addition I threw in an event to dump some info out.
> 
> event  bro_init()
> {
> 	print  fmt("-- signature_files = [%s]", signature_files);
> 
> 	# the http_servers is readable but by no means pretty.
> 	print  fmt("-- http_servers = [%s]", http_servers);
> }
> 
> Note: I'm no expert but I believe http_servers is signficant for a number
of
> the snort signatures.
> 
> For what its worth, I've been attempting to compare snort vs bro for a
class
> (perhaps like you are) and evidently I'm doing something wrong since I
get
> dozens of unique alerts (or alarms) in snort, but only 3 unique ones in
bro.
> I'm sure it is  a configuration problem but if anyone wants to volunteer
any
> suggestions it would be appreciated.
> 
> thanks.
> 
> john
> 
> 	
> 
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
> 




From jomcn at mail.com  Sun Dec  5 16:44:54 2004
From: jomcn at mail.com (john mcnicholas)
Date: Sun, 5 Dec 2004 19:44:54 -0500
Subject: [Bro] Off-line analysis
Message-ID: <20041206004447.MEOS1339.out014.verizon.net@achilles>

> Anyhow, what I really want to know is to do some ID attack ananlsys using
Bro.
> If you have experienced such things with Bro, please let me know.
> I get some tcpdump raw file, but it is not easy to handle Bro for offline
> test. 

I'll gladly try to help once I figure out my nagging issues.  Hopefully that
will be before Tuesday.

john



From vern at icir.org  Sun Dec  5 16:49:35 2004
From: vern at icir.org (Vern Paxson)
Date: Sun, 05 Dec 2004 16:49:35 -0800
Subject: [Bro] Off-line analysis
In-Reply-To: Your message of Sun, 05 Dec 2004 17:13:38 CST.
Message-ID: <200412060049.iB60nZSw026355@jaguar.icir.org>

> I first have to make "my own".bro, and then add the "my own.bro" file to
> policy setting in bro.cfg?

No, bro.cfg is for (somewhat) turnkey operational use.  For your
own offline analysis, you should ignore it and just create your
own file my-own.bro and then use

	bro -r tracefile my-own

to process it.

		Vern


From shonx001 at umn.edu  Sun Dec  5 17:58:05 2004
From: shonx001 at umn.edu (shonx001)
Date: Sun, 05 Dec 2004 19:58:05 CST
Subject: [Bro] Off-line analysis
Message-ID: <200412060158.iB61w5vJ002851@trojan.software.umn.edu>

Thanks.
Anyway, I will try to follow Vern's advice.
If you get some other brilliant idea, please let me know!

On 5 Dec 2004, john mcnicholas wrote:
> > Anyhow, what I really want to know is to do some ID attack ananlsys
using
> Bro.
> > If you have experienced such things with Bro, please let me know.
> > I get some tcpdump raw file, but it is not easy to handle Bro for
offline
> > test. 
> 
> I'll gladly try to help once I figure out my nagging issues.  Hopefully
that
> will be before Tuesday.
> 
> john
> 
> 




From christian at whoop.org  Wed Dec  8 04:45:00 2004
From: christian at whoop.org (Christian Kreibich)
Date: Wed, 08 Dec 2004 12:45:00 +0000
Subject: [Bro] About IDs in MutableVals
In-Reply-To: <20041203172204.GC23882@net.informatik.tu-muenchen.de>
References: <1102084044.28111.384.camel@localhost>
	 <20041203151638.GA27236@net.informatik.tu-muenchen.de>
	 <1102088954.28106.400.camel@localhost>
	 <20041203172204.GC23882@net.informatik.tu-muenchen.de>
Message-ID: <1102509900.18084.88.camel@localhost>

Hi Robin,

On Fri, 2004-12-03 at 17:22, Robin Sommer wrote:
> On Fri, Dec 03, 2004 at 15:49 +0000, Christian Kreibich wrote:
> 
> > Okay it's much clearer now, thanks! I guess what's still confusing me is
> > why is this happening at the MutableVal level and not in Vals directly?
> 
> Basically it's just an optimization. We could just as well assign
> global names to all values -- but we don't need to. A global name is
> only required when a Val can actually be changed. If it can't, it

Do you mean "can be changed" as opposed to "be replaced by a new val"?

> will never be referenced by one of the operations transfered during
> synchronization (for example, an assignment to an integer always
> creates a new Val and destroys the old one).

So when a field's value in a mutable val changes, it's the mutable val
that is flagged as changed and not that individual val -- is that it?

> Optimizing even further, we need only assign global names to MutableVals
> which are actually synchronized (or, in the future, persistent).

I think that's what's confusing me. A better way to put my question is
probably: if I want a val to be synchronized/persistent, it seems it has
to be a mutable val (i.e., a table/set or a record). Right?

> > I think this also comes back to the properties in MutableVals that I
> > don't quite understand -- why are these not attributes?
> 
> Which kind of attributes are you refering to? (The term "attribute"
> is quite is overloaded in Bro...). The attributes which are
> associated with Vals are RecordVals which don't really fit here
> (frankly, right now I can't remember what they are for... :-). The
> attributes associated with IDs are more appropiate (and, in fact,
> there are ATTR_SYNCHRONIZED/ATTR_PERSISTENT for IDs). But in
> general, values contained in MutableVals are not bound to any ID.
> Therefore, these attributes don't help for Vals.

Ah right! I meant the ones associated with vals, but I didn't think of
the val/id difference in context of the serialization. Thanks!

Cheers,
Christian.
-- 
________________________________________________________________________
                                          http://www.cl.cam.ac.uk/~cpk25
                                                    http://www.whoop.org




From shonx001 at umn.edu  Thu Dec  9 22:55:16 2004
From: shonx001 at umn.edu (shonx001)
Date: Fri, 10 Dec 2004 00:55:16 CST
Subject: [Bro] Off-line analysis
Message-ID: <200412100655.iBA6tGXl030711@firefox.software.umn.edu>

On 5 Dec 2004, Vern Paxson wrote:
> > I first have to make "my own".bro, and then add the "my own.bro" file
to
> > policy setting in bro.cfg?
> 
> No, bro.cfg is for (somewhat) turnkey operational use.  For your
> own offline analysis, you should ignore it and just create your
> own file my-own.bro and then use
> 
> 	bro -r tracefile my-own
> 
> to process it.
> 
> 		Vern
> 




From shonx001 at umn.edu  Thu Dec  9 22:58:52 2004
From: shonx001 at umn.edu (shonx001)
Date: Fri, 10 Dec 2004 00:58:52 CST
Subject: [Bro] Off-line analysis II
Message-ID: <200412100658.iBA6wqDE030835@firefox.software.umn.edu>

Dear Great Researchers,

When I tried to do Bro Offline test, I just got many ***.log files about
dos dump, normal dump, and so on.
However, when I tried to do that in real time mode, I could have various
alert about real time packets. 

Could you let me know how I can obtain more realistic Bro alert result in
OFF-Line Analysis?

Thx.

Have a great weekend with Bro!!!

Best Regards,
Taeshik




From christian at whoop.org  Fri Dec 10 02:20:35 2004
From: christian at whoop.org (Christian Kreibich)
Date: Fri, 10 Dec 2004 10:20:35 +0000
Subject: [Bro] Off-line analysis II
In-Reply-To: <200412100658.iBA6wqDE030835@firefox.software.umn.edu>
References: <200412100658.iBA6wqDE030835@firefox.software.umn.edu>
Message-ID: <1102674035.7035.17.camel@localhost>

Hi,

On Fri, 2004-12-10 at 06:58, shonx001 wrote:
> Dear Great Researchers,
> 
> When I tried to do Bro Offline test, I just got many ***.log files about
> dos dump, normal dump, and so on.
> However, when I tried to do that in real time mode, I could have various
> alert about real time packets. 
> 
> Could you let me know how I can obtain more realistic Bro alert result in
> OFF-Line Analysis?

there is absolutely no difference between using trace files (I presume
that's what you mean by "offline") and real traffic in the output
generated by Bro. What you get as output when reading in trace files is
exactly the same you'd get if you had seen those packets on a live
network.

Cheers,
Christian.
-- 
________________________________________________________________________
                                          http://www.cl.cam.ac.uk/~cpk25
                                                    http://www.whoop.org




From shonx001 at umn.edu  Fri Dec 10 08:09:26 2004
From: shonx001 at umn.edu (shonx001)
Date: Fri, 10 Dec 2004 10:09:26 CST
Subject: [Bro] Off-line analysis II
Message-ID: <200412101609.iBAG9QUl010642@fantasy.software.umn.edu>

If so, you mean that first real traffic result and second trace result have
just different log file name?
In the case of real time, "attack"."server name".date info
In the case of off-line, "attack".log  
???


 active_log
-rw-r--r--  1 root root     0 2004-12-11 01:05 alarm.cist.04-12-11_01.05.10
-rw-r--r--  1 root root     0 2004-12-11 01:05 conn.cist.04-12-11_01.05.10
-rw-r--r--  1 root root     0 2004-12-11 01:05 ftp.cist.04-12-11_01.05.10
-rw-r--r--  1 root root     0 2004-12-11 01:05 http.cist.04-12-11_01.05.10
-rw-r--r--  1 root root   787 2004-12-11 01:05 info.cist.04-12-11_01.05.10
-rw-r--r--  1 root root     0 2004-12-11 01:05
notice.cist.04-12-11_01.05.10
-rw-r--r--  1 root root     0 2004-12-11 01:05
signatures.cist.04-12-11_01.05.10
-rw-r--r--  1 root root     0 2004-12-11 01:05 smtp.cist.04-12-11_01.05.10
-rw-r--r--  1 root root     0 2004-12-11 01:05
software.cist.04-12-11_01.05.10
-rw-r--r--  1 root root 12288 2004-12-11 01:05 weird.cist.04-12-11_01.05.10
-rw-r--r--  1 root root     0 2004-12-11 01:05 worm.cist.04-12-11_01.05.10


-rw-r--r--  1 root root     5478 2004-12-10 14:04 alarm.log
-rw-r--r--  1 root root     3828 2004-12-10 14:04 backdoor.log
-rw-r--r--  1 root root  4430446 2004-12-10 14:04 conn.log
-rw-r--r--  1 root root   992902 2004-12-10 14:04 dns.log
-rw-r--r--  1 root root   122129 2004-12-10 14:04 ftp.log
-rw-r--r--  1 root root 12178262 2004-12-10 14:04 http.log
-rw-r--r--  1 root root   124416 2004-12-10 14:04 icmp.log
-rw-r--r--  1 root root  5376365 2004-12-10 14:04 mime.log
-rw-r--r--  1 root root     9499 2004-12-10 14:04 notice.log
-rw-r--r--  1 root root   561990 2004-12-10 14:04 relay.log
-rw-r--r--  1 root root        0 2004-12-10 14:02 signatures.log
-rw-r--r--  1 root root  1681584 2004-12-10 14:04 smtp.log
-rw-r--r--  1 root root        0 2004-12-10 14:02 software.log
-rw-r--r--  1 root root     5899 2004-12-10 14:04 ssh.log
-rw-r--r--  1 root root        0 2004-12-10 14:02 step.log
-rw-r--r--  1 root root  2505550 2004-12-10 14:04 weird.log
-rw-r--r--  1 root root        0 2004-12-10 14:02 worm.log
drwxr-xr-x  2 root root     4096 2004-12-10 14:03 xscript.log



On 10 Dec 2004, Christian Kreibich wrote:
> Hi,
> 
> On Fri, 2004-12-10 at 06:58, shonx001 wrote:
> > Dear Great Researchers,
> > 
> > When I tried to do Bro Offline test, I just got many ***.log files
about
> > dos dump, normal dump, and so on.
> > However, when I tried to do that in real time mode, I could have
various
> > alert about real time packets. 
> > 
> > Could you let me know how I can obtain more realistic Bro alert result
in
> > OFF-Line Analysis?
> 
> there is absolutely no difference between using trace files (I presume
> that's what you mean by "offline") and real traffic in the output
> generated by Bro. What you get as output when reading in trace files is
> exactly the same you'd get if you had seen those packets on a live
> network.
> 
> Cheers,
> Christian.
> -- 
> ________________________________________________________________________
>                                           http://www.cl.cam.ac.uk/~cpk25
>                                                     http://www.whoop.org
> 
> 
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
> 




From scampbell at lbl.gov  Fri Dec 10 10:18:57 2004
From: scampbell at lbl.gov (scott campbell)
Date: Fri, 10 Dec 2004 10:18:57 -0800
Subject: [Bro] Off-line analysis II
In-Reply-To: <200412101609.iBAG9QUl010642@fantasy.software.umn.edu>
References: <200412101609.iBAG9QUl010642@fantasy.software.umn.edu>
Message-ID: <41B9E891.3050006@lbl.gov>

The logs in question are just being named differently by the differing 
mechanisms that are running bro.  When bro runs, it checks for an 
environmental variable called BRO_LOG_SUFFIX which it appends to the end 
of the file name.  When you manually run bro, typically this is not 
defined and you get ex:

alarm.log

When you start bro via the bro.rc script, the value is defined and you 
get a file name of :

alarm.cist.04-12-11_01.05.10

This was put in place to prevent file name collisions on long running boxes.

What bro puts into the files is the same in both cases.

Is this helpful?

scott


shonx001 wrote:
> If so, you mean that first real traffic result and second trace result have
> just different log file name?
> In the case of real time, "attack"."server name".date info
> In the case of off-line, "attack".log  
> ???
> 
> 
>  active_log
> -rw-r--r--  1 root root     0 2004-12-11 01:05 alarm.cist.04-12-11_01.05.10
> -rw-r--r--  1 root root     0 2004-12-11 01:05 conn.cist.04-12-11_01.05.10
> -rw-r--r--  1 root root     0 2004-12-11 01:05 ftp.cist.04-12-11_01.05.10
> -rw-r--r--  1 root root     0 2004-12-11 01:05 http.cist.04-12-11_01.05.10
> -rw-r--r--  1 root root   787 2004-12-11 01:05 info.cist.04-12-11_01.05.10
> -rw-r--r--  1 root root     0 2004-12-11 01:05
> notice.cist.04-12-11_01.05.10
> -rw-r--r--  1 root root     0 2004-12-11 01:05
> signatures.cist.04-12-11_01.05.10
> -rw-r--r--  1 root root     0 2004-12-11 01:05 smtp.cist.04-12-11_01.05.10
> -rw-r--r--  1 root root     0 2004-12-11 01:05
> software.cist.04-12-11_01.05.10
> -rw-r--r--  1 root root 12288 2004-12-11 01:05 weird.cist.04-12-11_01.05.10
> -rw-r--r--  1 root root     0 2004-12-11 01:05 worm.cist.04-12-11_01.05.10
> 
> 
> -rw-r--r--  1 root root     5478 2004-12-10 14:04 alarm.log
> -rw-r--r--  1 root root     3828 2004-12-10 14:04 backdoor.log
> -rw-r--r--  1 root root  4430446 2004-12-10 14:04 conn.log
> -rw-r--r--  1 root root   992902 2004-12-10 14:04 dns.log
> -rw-r--r--  1 root root   122129 2004-12-10 14:04 ftp.log
> -rw-r--r--  1 root root 12178262 2004-12-10 14:04 http.log
> -rw-r--r--  1 root root   124416 2004-12-10 14:04 icmp.log
> -rw-r--r--  1 root root  5376365 2004-12-10 14:04 mime.log
> -rw-r--r--  1 root root     9499 2004-12-10 14:04 notice.log
> -rw-r--r--  1 root root   561990 2004-12-10 14:04 relay.log
> -rw-r--r--  1 root root        0 2004-12-10 14:02 signatures.log
> -rw-r--r--  1 root root  1681584 2004-12-10 14:04 smtp.log
> -rw-r--r--  1 root root        0 2004-12-10 14:02 software.log
> -rw-r--r--  1 root root     5899 2004-12-10 14:04 ssh.log
> -rw-r--r--  1 root root        0 2004-12-10 14:02 step.log
> -rw-r--r--  1 root root  2505550 2004-12-10 14:04 weird.log
> -rw-r--r--  1 root root        0 2004-12-10 14:02 worm.log
> drwxr-xr-x  2 root root     4096 2004-12-10 14:03 xscript.log
> 
> 
> 
> On 10 Dec 2004, Christian Kreibich wrote:
> 
>>Hi,
>>
>>On Fri, 2004-12-10 at 06:58, shonx001 wrote:
>>
>>>Dear Great Researchers,
>>>
>>>When I tried to do Bro Offline test, I just got many ***.log files
> 
> about
> 
>>>dos dump, normal dump, and so on.
>>>However, when I tried to do that in real time mode, I could have
> 
> various
> 
>>>alert about real time packets. 
>>>
>>>Could you let me know how I can obtain more realistic Bro alert result
> 
> in
> 
>>>OFF-Line Analysis?
>>
>>there is absolutely no difference between using trace files (I presume
>>that's what you mean by "offline") and real traffic in the output
>>generated by Bro. What you get as output when reading in trace files is
>>exactly the same you'd get if you had seen those packets on a live
>>network.
>>
>>Cheers,
>>Christian.
>>-- 
>>________________________________________________________________________
>>                                          http://www.cl.cam.ac.uk/~cpk25
>>                                                    http://www.whoop.org
>>
>>
>>_______________________________________________
>>Bro mailing list
>>bro at bro-ids.org
>>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>>
> 
> 
> 
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20041210/d3aa26d1/attachment.bin 

From shonx001 at umn.edu  Fri Dec 10 12:37:36 2004
From: shonx001 at umn.edu (shonx001)
Date: Fri, 10 Dec 2004 14:37:36 CST
Subject: [Bro] Segmentation fault at Off-line test
Message-ID: <200412102037.iBAKbalE009700@firefox.software.umn.edu>

?Hi all,
 
 When I tried to test Bro in off-line with TCP dump file, I met
segmentation falut error.

 The tcpdump was captured using "Targa2.c" with all supported attacks.

 Also, I used the "my own.bro" in accordance with former mailing list
written by Vern about off-line test.

 What I used command is as follows:

 . /bro.cfg
 ./bro -r "dumpfile" "my own.bro"


 refer to "my own.bro"
 
         @load site
	@load mt
	@load tftp
	@load dns
	@load flag-irc
	@load smtp-relay
	@load software
	@load ssh
	@load worm
	@load backdoor.bro
	@load blaster.bro
	@load flag-warez.bro
	@load gnutella.bro
	@load http-abstract.bro
	@load http-body.bro
	@load http-reply.bro
	@load icmp.bro
	@load ssl-worm.bro
	@load stepping.bro
	@load synflood.bro


 Thanks

 Taeshik




From vern at icir.org  Fri Dec 10 16:56:25 2004
From: vern at icir.org (Vern Paxson)
Date: Fri, 10 Dec 2004 16:56:25 -0800
Subject: [Bro] Segmentation fault at Off-line test
In-Reply-To: Your message of Fri, 10 Dec 2004 14:37:36 CST.
Message-ID: <200412110056.iBB0uPjp087274@jaguar.icir.org>

>  When I tried to test Bro in off-line with TCP dump file, I met
> segmentation falut error.

When reporting such an error, you need to include a traceback from the
debugger.

If you can send us the tracefile, we will look into reproducing the
problem.

		Vern


From rmkml at wanadoo.fr  Sat Dec 11 05:48:12 2004
From: rmkml at wanadoo.fr (rmkml)
Date: Sat, 11 Dec 2004 14:48:12 +0100 (CET)
Subject: [Bro] Segmentation fault at Off-line test
In-Reply-To: <200412102037.iBAKbalE009700@firefox.software.umn.edu>
References: <200412102037.iBAKbalE009700@firefox.software.umn.edu>
Message-ID: <Pine.LNX.4.61.0412111442000.1124@hp.>

Hi,

Im downloaded targa2 :

http://mvb.saic.com/freeware/vmslt99b/sec/targa2.c

compiled on linux 2.6.9

running on linux (./targa2 192.168.1.1 192.168.1.1 -t 0),

network dump to targa2.tcpdump (-ns0 -i eth0),

  (join file)

run bro09a7 on fbsd410R

with "my own.bro"

and no pb.

what os use ?
what bro version use ?

Regards

Rmkml at Wanadoo.fr



On Fri, 10 Dec 2004, shonx001 wrote:

> Date: Fri, 10 Dec 2004 14:37:36 CST
> From: shonx001 <shonx001 at umn.edu>
> To: bro at bro-ids.org
> Subject: [Bro] Segmentation fault at Off-line test
> 
> ?Hi all,
>
> When I tried to test Bro in off-line with TCP dump file, I met
> segmentation falut error.
>
> The tcpdump was captured using "Targa2.c" with all supported attacks.
>
> Also, I used the "my own.bro" in accordance with former mailing list
> written by Vern about off-line test.
>
> What I used command is as follows:
>
> . /bro.cfg
> ./bro -r "dumpfile" "my own.bro"
>
>
> refer to "my own.bro"
>
>         @load site
> 	@load mt
> 	@load tftp
> 	@load dns
> 	@load flag-irc
> 	@load smtp-relay
> 	@load software
> 	@load ssh
> 	@load worm
> 	@load backdoor.bro
> 	@load blaster.bro
> 	@load flag-warez.bro
> 	@load gnutella.bro
> 	@load http-abstract.bro
> 	@load http-body.bro
> 	@load http-reply.bro
> 	@load icmp.bro
> 	@load ssl-worm.bro
> 	@load stepping.bro
> 	@load synflood.bro
>
>
> Thanks
>
> Taeshik
>
>
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: targa2.tcpdump.bz2
Type: application/octet-stream
Size: 19967 bytes
Desc: 
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20041211/e76bdbb0/attachment.obj 

From vern at icir.org  Sun Dec 12 16:33:00 2004
From: vern at icir.org (Vern Paxson)
Date: Sun, 12 Dec 2004 16:33:00 -0800
Subject: [Bro] Segmentation fault at Off-line test
In-Reply-To: Your message of Fri, 10 Dec 2004 14:37:36 CST.
Message-ID: <200412130033.iBD0X0TG052827@jaguar.icir.org>

>  When I tried to test Bro in off-line with TCP dump file, I met
> segmentation falut error.
> 
>  The tcpdump was captured using "Targa2.c" with all supported attacks.

While I couldn't reproduce the crash using the trace you subsequently sent
me, the heavy use of fragments makes me suspect it's the same fragment bug
that I fixed a few days ago (and will be included in the next release).
I've attached diffs for it in case you want to try directly.  Note that
for the trace you sent me, Bro takes a *long* time to process it, since
every packet in it generates multiple events.  Fixing this sort of performance
problem is clearly important and on our radar, but it can be quite hard,
so it will remain an issue.

		Vern


Index: Frag.cc
===================================================================
RCS file: /home/portnoy/u2/src/projects/bro/src/Frag.cc,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -u -r1.1 -r1.2
--- Frag.cc	14 Jul 2004 20:15:40 -0000	1.1
+++ Frag.cc	10 Dec 2004 18:19:47 -0000	1.2
@@ -1,4 +1,4 @@
-// $Id: Frag.cc,v 1.1 2004/07/14 20:15:40 jason Exp $
+// $Id: Frag.cc,v 1.2 2004/12/10 18:19:47 vern Exp $
 //
 // Copyright (c) 1998, 1999, 2001, 2002
 //      The Regents of the University of California.  All rights reserved.
@@ -161,10 +161,11 @@
 	if ( b->next )
 		{
 		// We have a hole.
-		if ( b->seq >= frag_size )
+		if ( b->upper >= frag_size )
 			{
 			IP_Hdr proto_h((const struct ip*) proto_hdr);
 			s->Weird("fragment_size_inconsistency", &proto_h);
+			frag_size = b->upper;
 			}
 		else
 			return;
@@ -174,6 +175,7 @@
 		{
 		IP_Hdr proto_h((const struct ip*) proto_hdr);
 		s->Weird("fragment_size_inconsistency", &proto_h);
+		frag_size = last_block->upper;
 		}
 
 	else if ( last_block->upper < frag_size )


From y-gao2 at northwestern.edu  Thu Dec 16 10:18:55 2004
From: y-gao2 at northwestern.edu (yangao)
Date: Thu, 16 Dec 2004 12:18:55 -0600
Subject: [Bro] flow-level analysis code
References: <200412161739.iBGHd18f014269@fruitcake.ICSI.Berkeley.EDU>
Message-ID: <002e01c4e39b$b49cfdc0$86646981@cs.northwestern.edu>

Hi,

I think Bro is really a good tool for intrusion detection. However, after I 
studied the reference manual, I found for offline analysis it can only use 
tcpdump packet level input. Could it also use flow-level analysis data as 
input? I want to detect some scan and SYN flooding attacks, does somebody 
have this kind of flow-level code or experience on this? If so, could you 
share it with us? Our purpose is purely for research.
Thx.

Yan Gao 



From rreitz at fnal.gov  Thu Dec 16 12:22:19 2004
From: rreitz at fnal.gov (Randolph Reitz)
Date: Thu, 16 Dec 2004 14:22:19 -0600
Subject: [Bro] flow-level analysis code
In-Reply-To: <002e01c4e39b$b49cfdc0$86646981@cs.northwestern.edu>
References: <200412161739.iBGHd18f014269@fruitcake.ICSI.Berkeley.EDU>
 <002e01c4e39b$b49cfdc0$86646981@cs.northwestern.edu>
Message-ID: <2F4C9FCB-4FA0-11D9-8D3B-000A95D15230@fnal.gov>

Fermilab uses a package named 'flow-tools' that was originally 
developed at Ohio State Unix.  The first Google hit is...

http://www.splintered.net/sw/flow-tools/

Randy Reitz
Computer Security Team

On Dec 16, 2004, at 12:18 PM, yangao wrote:

> Hi,
>
> I think Bro is really a good tool for intrusion detection. However, 
> after I studied the reference manual, I found for offline analysis it 
> can only use tcpdump packet level input. Could it also use flow-level 
> analysis data as input? I want to detect some scan and SYN flooding 
> attacks, does somebody have this kind of flow-level code or experience 
> on this? If so, could you share it with us? Our purpose is purely for 
> research.
> Thx.
>
> Yan Gao
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro



From vern at icir.org  Thu Dec 16 22:53:02 2004
From: vern at icir.org (Vern Paxson)
Date: Thu, 16 Dec 2004 22:53:02 -0800
Subject: [Bro] flow-level analysis code 
In-Reply-To: Your message of Thu, 16 Dec 2004 12:18:55 CST.
Message-ID: <200412170653.iBH6r2fJ049571@jaguar.icir.org>

> Could it also use flow-level analysis data as 
> input?

At present, no.  Some folks have discussed adding support for reading
NetFlow records, but as far as I know, no one is working on this.

		Vern


From jp.luiggi at free.fr  Fri Dec 17 01:36:55 2004
From: jp.luiggi at free.fr (Jean-Philippe Luiggi)
Date: Fri, 17 Dec 2004 10:36:55 +0100
Subject: [Bro] flow-level analysis code
In-Reply-To: <200412170653.iBH6r2fJ049571@jaguar.icir.org>
References: <200412170653.iBH6r2fJ049571@jaguar.icir.org>
Message-ID: <20041217093655.GA12055@leia.local>

Hello,

I use Netflow every day and it may be a good thing to use it inside Bro.
Who's interested on this topic ?
I think i (we) may start something.  

Best regards.


On Thu, Dec 16, 2004 at 10:53:02PM -0800, Vern Paxson wrote:
> > Could it also use flow-level analysis data as 
> > input?
> 
> At present, no.  Some folks have discussed adding support for reading
> NetFlow records, but as far as I know, no one is working on this.
> 
> 		Vern
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro

-- 

[Jean-Philippe Luiggi (jp.luiggi at free.fr)]




From anton at netForensics.com  Fri Dec 17 11:32:32 2004
From: anton at netForensics.com (Anton Chuvakin, Ph.D.)
Date: Fri, 17 Dec 2004 14:32:32 -0500 (EST)
Subject: [Bro] flow-level analysis code
In-Reply-To: <20041217093655.GA12055@leia.local>
References: <200412170653.iBH6r2fJ049571@jaguar.icir.org><20041217093655.GA12055@leia.local>
Message-ID: <Pine.LNX.4.61.0412171431150.20440@anton.netforensics.com>

> I use Netflow every day and it may be a good thing to use it inside Bro.
> Who's interested on this topic ?
> I think i (we) may start something.

I am very interested, but it seems that it is somewhat outside the scope 
of Bro as a classic NIDS. Reading netflow will make no sense (for Bro) 
since there is no packet contents.

Best,
-- 
Anton Chuvakin, Ph.D., GCIA, GCIH - http://www.info-secure.org
Author of "Security Warrior" from O'Reilly - http://www.securitywarrior.com
Chief Security Strategist
Product Management Group
netForensics -  http://www.netForensics.com
**************************************************************************************************
The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or  the 
sender immediately and do not disclose the contents to anyone or make copies.

** netForensics has  scanned this email for viruses, vandals and malicious content. **
**************************************************************************************************


From vern at icir.org  Fri Dec 17 11:46:34 2004
From: vern at icir.org (Vern Paxson)
Date: Fri, 17 Dec 2004 11:46:34 -0800
Subject: [Bro] flow-level analysis code
In-Reply-To: Your message of Fri, 17 Dec 2004 14:32:32 EST.
Message-ID: <200412171946.iBHJkYbZ062676@jaguar.icir.org>

> I am very interested, but it seems that it is somewhat outside the scope 
> of Bro as a classic NIDS. Reading netflow will make no sense (for Bro) 
> since there is no packet contents.

Actually, I think it does make sense.  Bro can do a fair amount of analysis
based on TCP SYN/FIN/RST packets and UDP request/replies without seeing
packet contents.  For example, its scan detection is driven off of this
level of information.

		Vern


From anton at netForensics.com  Fri Dec 17 12:16:27 2004
From: anton at netForensics.com (Anton Chuvakin, Ph.D.)
Date: Fri, 17 Dec 2004 15:16:27 -0500 (EST)
Subject: [Bro] flow-level analysis code
In-Reply-To: <200412171946.iBHJkYbZ062676@jaguar.icir.org>
References: <200412171946.iBHJkYbZ062676@jaguar.icir.org>
Message-ID: <Pine.LNX.4.61.0412171514370.20736@anton.netforensics.com>

>> I am very interested, but it seems that it is somewhat outside the scope
>> of Bro as a classic NIDS. Reading netflow will make no sense (for Bro)
>> since there is no packet contents.

> Actually, I think it does make sense.  Bro can do a fair amount of analysis
> based on TCP SYN/FIN/RST packets and UDP request/replies without seeing
> packet contents.  For example, its scan detection is driven off of this
> level of information.

But where you will take it beyond scans?

Maybe automatic 'stepping stone' detection based on flows? Or flow 
profiling (for backdoors and trojans with new prots)? It looks like it 
will be a very different product as a result.

Also, in this case we will see neither contents nor the header, just the 
fact that seesion took place.

Best,
-- 
Anton Chuvakin, Ph.D., GCIA, GCIH
Author of "Security Warrior" from O'Reilly - http://www.securitywarrior.com
Security Strategist
Product Management Group
netForensics -  http://www.netForensics.com
**************************************************************************************************
The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or  the 
sender immediately and do not disclose the contents to anyone or make copies.

** netForensics has  scanned this email for viruses, vandals and malicious content. **
**************************************************************************************************


From jp.luiggi at free.fr  Sat Dec 18 11:09:38 2004
From: jp.luiggi at free.fr (jean-philippe luiggi)
Date: Sat, 18 Dec 2004 20:09:38 +0100
Subject: [Bro] flow-level analysis code
In-Reply-To: <Pine.LNX.4.61.0412171431150.20440@anton.netforensics.com>
References: <200412170653.iBH6r2fJ049571@jaguar.icir.org><20041217093655.GA12055@leia.local> <Pine.LNX.4.61.0412171431150.20440@anton.netforensics.com>
Message-ID: <41C48072.4070901@free.fr>

Anton Chuvakin, Ph.D. wrote:

>> I use Netflow every day and it may be a good thing to use it inside Bro.
>> Who's interested on this topic ?
>> I think i (we) may start something.
>
>
> I am very interested, but it seems that it is somewhat outside the 
> scope of Bro as a classic NIDS. Reading netflow will make no sense 
> (for Bro) since there is no packet contents.
>
> Best,

Hello Anton,

If I'm not wrong Bro just see the 'local' network, it doesn't work likes a
distributed IDS. On another side, it's sure that using Netflow does not 
give us the ability to see the payload but with Netflow
- We could see network scan
- We could see some 'not usual' traffic which may break the security's 
rules

So may be using this feature would give us some new 'nice' informations ?



From vern at icir.org  Sat Dec 18 18:02:47 2004
From: vern at icir.org (Vern Paxson)
Date: Sat, 18 Dec 2004 18:02:47 -0800
Subject: [Bro] flow-level analysis code
In-Reply-To: Your message of Fri, 17 Dec 2004 15:16:27 EST.
Message-ID: <200412190202.iBJ22lOW013904@jaguar.icir.org>

> > Actually, I think it does make sense.  Bro can do a fair amount of analysis
> > based on TCP SYN/FIN/RST packets and UDP request/replies without seeing
> > packet contents.  For example, its scan detection is driven off of this
> > level of information.
> 
> But where you will take it beyond scans?

As Jean-Philippe mentioned in his reply, you can use it for forms of
analysis along the lines of "host A contacted host B and host B replied,
is that allowed?"  For some forms of contact, you can't really do this
without having packet contents, since host B may have replied at the app
layer saying "I refuse to talk to you", but for other forms you can tell
if proscribed communication occurred just by the volumes of data transferred
in each direction.

> Maybe automatic 'stepping stone' detection based on flows? Or flow 
> profiling (for backdoors and trojans with new prots)?

Yes, for some of that too.  I'm also working with some students on detecting
some other types of anomalies that indicate likely attacks that work at
this level.

		Vern


From vern at icir.org  Sat Dec 18 18:06:45 2004
From: vern at icir.org (Vern Paxson)
Date: Sat, 18 Dec 2004 18:06:45 -0800
Subject: [Bro] flow-level analysis code
In-Reply-To: Your message of Sat, 18 Dec 2004 20:09:38 +0100.
Message-ID: <200412190206.iBJ26jR6014005@jaguar.icir.org>

> If I'm not wrong Bro just see the 'local' network

More precisely, just see what transits whatever link(s) for which it has
taps.  Also, the ability of Bro's to exchange events allows a broader set
of perspectives to be integrated, though we haven't put this together
operationally yet (we will soon).  In addition, the Bro client library
(Broccoli) allows integration of host events into the network analysis.
One interesting example here is an sshd instrumented to tell Bro about
authentication attempts/successes, as well as possibly sending it the clear
text of a login session (yes, a scary thought!; this happens over SSL, not
in the clear, but still gives some people the heeby-jeebies).  We have
a prototype of that pretty much done.

		Vern


From jp.luiggi at free.fr  Sun Dec 19 08:13:35 2004
From: jp.luiggi at free.fr (jean-philippe luiggi)
Date: Sun, 19 Dec 2004 17:13:35 +0100
Subject: [Bro] flow-level analysis code
In-Reply-To: <200412190202.iBJ22lOW013904@jaguar.icir.org>
References: <200412190202.iBJ22lOW013904@jaguar.icir.org>
Message-ID: <41C5A8AF.6050608@free.fr>

Vern Paxson wrote:

>>Maybe automatic 'stepping stone' detection based on flows? Or flow 
>>profiling (for backdoors and trojans with new prots)?
>>    
>>
>
>Yes, for some of that too.  I'm also working with some students on detecting
>some other types of anomalies that indicate likely attacks that work at
>this level.
>
>		Vern
>  
>
In fact using Bro/Netflow with "stepping stone" detection in mind is a 
very interestant concept,
likes all flows coming from the "outside" must travel something likes a 
router (normally), we've the ability to see and detecting a problem 
quickly (using the correct analyzer).








From christian at whoop.org  Sun Dec 19 11:20:16 2004
From: christian at whoop.org (Christian Kreibich)
Date: Sun, 19 Dec 2004 19:20:16 +0000
Subject: [Bro] flow-level analysis code
In-Reply-To: <41C48072.4070901@free.fr>
References: <200412170653.iBH6r2fJ049571@jaguar.icir.org>
	 <20041217093655.GA12055@leia.local>
	 <Pine.LNX.4.61.0412171431150.20440@anton.netforensics.com>
	 <41C48072.4070901@free.fr>
Message-ID: <1103484017.3186.36.camel@localhost>

Hi,

I think it's important that people take a very open stance when
considering what's useful to Bro. Bro is not just a signature matcher.
As Vern indicated when mentioning scan detection, it's not necessarily
about packet contents -- if you want that and only that then use snort
(after making sure that our Bro rules don't do at least as good a job :)
The protocol headers give you a lot of information when it comes to
inferring communication patterns, communities of interest, connection
behaviour, traffic volume, etc. It all depends on your policy. 

Also, Bro's actually on the brink of becoming really quite distributed.
Bro can already exchange essentially arbitrary state with other Bro
nodes (have a look at the remote.bro and listen-ssl.bro policies) --
this includes policies, connection state, policy state, etc. We can do
Bro-Bro handovers, communicate with non-Bro agents, you name it. I'm not
aware of any other system that comes close to this. It's still being
polished and not widely known yet, but it's coming :)

Thanks,
Christian.

On Sat, 2004-12-18 at 20:09 +0100, jean-philippe luiggi wrote:
> Anton Chuvakin, Ph.D. wrote:
> 
> >> I use Netflow every day and it may be a good thing to use it inside Bro.
> >> Who's interested on this topic ?
> >> I think i (we) may start something.
> >
> >
> > I am very interested, but it seems that it is somewhat outside the 
> > scope of Bro as a classic NIDS. Reading netflow will make no sense 
> > (for Bro) since there is no packet contents.
> >
> > Best,
> 
> Hello Anton,
> 
> If I'm not wrong Bro just see the 'local' network, it doesn't work likes a
> distributed IDS. On another side, it's sure that using Netflow does not 
> give us the ability to see the payload but with Netflow
> - We could see network scan
> - We could see some 'not usual' traffic which may break the security's 
> rules
> 
> So may be using this feature would give us some new 'nice' informations ?

-- 
________________________________________________________________________
                                          http://www.cl.cam.ac.uk/~cpk25
                                                    http://www.whoop.org




From gefonty at yahoo.com.cn  Wed Dec 22 09:42:09 2004
From: gefonty at yahoo.com.cn (=?gb2312?q?=C1=C1=20=C0=EE?=)
Date: Thu, 23 Dec 2004 01:42:09 +0800 (CST)
Subject: [Bro] problem of multi-interface monitor?
Message-ID: <20041222174209.52728.qmail@web15508.mail.cnb.yahoo.com>

Hello,
when i execute "bro -i eth0 -i eth1 login.bro",bro only capture and deal with packets from eth0 and drop all from eth1.
 
"1103734623.487821:ContentGap:NOTICE_ALARM_ALWAYS::192.168.10.10:2422/tcp:192.168.10.77:23/tcp::::::192.168.10.10/2422         > 192.168.10.77/telnet content gap (> 69/11):"
 
after that,i emove "capture-filter ......" fom login.bro and try again,bro can capture and do rightly.
 
why? and how can i solve this problem?
 
sorry,i am not familiar whit BRO.
 



---------------------------------
Do You Yahoo!?
???????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20041223/c14e2e2d/attachment.html 

From goeldich at ee.ethz.ch  Fri Dec 24 04:24:15 2004
From: goeldich at ee.ethz.ch (Christoph Goeldi)
Date: Fri, 24 Dec 2004 13:24:15 +0100
Subject: [Bro] Questions
Message-ID: <41CC0A6F.4030909@ee.ethz.ch>

hi


i'm currently working on my masterthesis here at the swiss federal 
institute of technology in zurich.
it's about "scan detection based identification of worm-infected hosts"
in small LANs.
now, i'm evaluating bro and try to use it for my purposes.
i'm currently using bro 0.9a7 on a linux pc and i'm trying to implement
some existing scan detection approaches.


here my questions:
- i'm not quite sure about the future plans of bro. will there be
a lot of big changes from now to the release of 1.0? incompatibilities?

- there exists a detection method which is based on the entropy of
ip headers (tuple: src, dst, src_port, dst_port). the algorithm stores 
this table of tuples every minute in a file and compresses it using
the LZO-compression-algorithm. then the size of the file is an indicator
for network anomalies.
now my question: how can i best implement this with bro? how can i use
the lzo-algorithm (which is available in C, java, perl...) to compress
my file every minute and get back the resulting file size?


thanx
christoph


From goeldich at ee.ethz.ch  Fri Dec 24 04:25:10 2004
From: goeldich at ee.ethz.ch (Christoph Goeldi)
Date: Fri, 24 Dec 2004 13:25:10 +0100
Subject: [Bro] problems with &*_expire attributes
Message-ID: <41CC0AA6.5030205@ee.ethz.ch>

hi

i'm fighting with some problems:
i encountered problems with the &*_expire attributes of table entries.
it seems that they have no influence, nothing happens at all.

i wrote the policy script below (don't ask for the purpose of this 
script, i just wrote it to learn bro) and i thought it should alarm more 
than once, if a host contacts unreachable hosts after a while. well, it 
does it only once and the function test is never called:
 > 1103883009.796358 TRWAddressScan x.x.x.x scanned a total of 4 hosts
 > 1103883009.796358 x.x.x.x connected 10 unreachable hosts
 > 1103883010.358487 AddressScan x.x.x.x has scanned 100 hosts (ftp-data)
 > 1103883010.358487 x.x.x.x connected 100 unreachable hosts
 > 1103883013.343568 x.x.x.x connected 1000 unreachable hosts
 > 1103883013.343568 AddressScan x.x.x.x has scanned 1000 hosts (ftp-data)
 > 1103883036.284724 TRWScanSummary x.x.x.x scanned a total of 4 hosts

btw: count_failed_attempts is called by the event connection_attempt in
conn.bro.
 > @load notice
 > @load conn
 > @load hot
 >
 > redef table_expire_interval = 1 min;
 > redef table_expire_size = 200;
 > redef table_expire_delay = 0.01 secs;
 >
 > global test: function(t: table[addr] of count, idx: any): interval;
 >
 > global failed_connection_counter: table[addr] of count &read_expire=30sec
 > &write_expire=30sec &create_expire=30sec &expire_func=test;
 >
 >
 > function count_failed_attempts(c: connection)
 >          {
 >          local host = c$id$orig_h;
 >          if(host !in failed_connection_counter)
 >                  failed_connection_counter[host]=1;
 >          else
 >                  ++failed_connection_counter[host];
 >
 >          local n = failed_connection_counter[host];
 >
 >          if(n == 10)
 >                 alarm fmt("%s connected 10 unreachable hosts", host);
 >          if(n == 100)
 >                 alarm fmt("%s connected 100 unreachable hosts", host);
 >          if(n == 1000)
 >                 alarm fmt("%s connected 1000 unreachable hosts", host);
 >          }
 >
 > function test(t: table[addr] of count, idx: any): interval
 > {
 >          alarm "test";
 >          return 0 secs;
 > }


thanx
christoph


From vern at icir.org  Mon Dec 27 22:44:59 2004
From: vern at icir.org (Vern Paxson)
Date: Mon, 27 Dec 2004 22:44:59 -0800
Subject: [Bro] Questions
In-Reply-To: Your message of Fri, 24 Dec 2004 13:24:15 +0100.
Message-ID: <200412280645.iBS6ix4L083187@jaguar.icir.org>

> - i'm not quite sure about the future plans of bro. will there be
> a lot of big changes from now to the release of 1.0? incompatibilities?

We don't have a precise roadmap, but of the anticipated changes, I don't
think any upcoming ones would be viewed as "big" for most Bro users.  There
also will be some incompatibilities, but likewise I don't imagine these
will be viewed as major by most Bro users.

> - there exists a detection method which is based on the entropy of
> ip headers (tuple: src, dst, src_port, dst_port). the algorithm stores 
> this table of tuples every minute in a file and compresses it using
> the LZO-compression-algorithm. then the size of the file is an indicator
> for network anomalies.

(Hmmmm, that seems a lot more coarse-grained than something like Bro's
TRW detector ....)

> now my question: how can i best implement this with bro? how can i use
> the lzo-algorithm (which is available in C, java, perl...) to compress
> my file every minute and get back the resulting file size?

If you really want to do that, the natural way would be to add it as a
built-in function (see src/bro.bif for how these are defined).  Ideally,
the function would compute it in an incremental fashion, so the result can
be updated a piece at a time in real-time.  Computing it in a batch every
minute or so, with a corresponding large CPU burst required, is not in
keeping with real-time analysis & detection.

		Vern


From vern at icir.org  Mon Dec 27 22:45:36 2004
From: vern at icir.org (Vern Paxson)
Date: Mon, 27 Dec 2004 22:45:36 -0800
Subject: [Bro] problems with &*_expire attributes
In-Reply-To: Your message of Fri, 24 Dec 2004 13:25:10 +0100.
Message-ID: <200412280645.iBS6jaXo083222@jaguar.icir.org>

> i'm fighting with some problems:
> i encountered problems with the &*_expire attributes of table entries.
> it seems that they have no influence, nothing happens at all.
> 
> i wrote the policy script below (don't ask for the purpose of this 
> script, i just wrote it to learn bro) and i thought it should alarm more 
> than once, if a host contacts unreachable hosts after a while. well, it 
> does it only once and the function test is never called:
>  > 1103883009.796358 TRWAddressScan x.x.x.x scanned a total of 4 hosts
>  > 1103883009.796358 x.x.x.x connected 10 unreachable hosts
>  > 1103883010.358487 AddressScan x.x.x.x has scanned 100 hosts (ftp-data)
>  > 1103883010.358487 x.x.x.x connected 100 unreachable hosts
>  > 1103883013.343568 x.x.x.x connected 1000 unreachable hosts
>  > 1103883013.343568 AddressScan x.x.x.x has scanned 1000 hosts (ftp-data)
>  > 1103883036.284724 TRWScanSummary x.x.x.x scanned a total of 4 hosts

What do you mean it should "alarm more than once"?  It is indeed generating
multiple alarms (10 unreachable, 100 unreachable, 1000 unreachable).

Also, you need to clarify why would you expect "test" to be called.
All of the expirations you set:

>  > global failed_connection_counter: table[addr] of count &read_expire=30sec
>  > &write_expire=30sec &create_expire=30sec &expire_func=test;

are for 30 seconds after the last of different types of activity, yet the
timestamps of the alarm output you show span just a few seconds, so this
doesn't appear to be enough time for any of the expirations to occur.

		Vern


From jyjung at csail.mit.edu  Mon Dec 27 23:11:16 2004
From: jyjung at csail.mit.edu (Jaeyeon Jung)
Date: Tue, 28 Dec 2004 02:11:16 -0500
Subject: [Bro] How to turn off logging Bro alerts via syslog
Message-ID: <20041228021116.A4652@csail.mit.edu>

We are running Bro 0.9a8.14 on our Linux system. We notice that
/ is often 100% full because of huge /var/log/messages, which
seems filled with the Bro alerts that are also recorded in its 
own alarm log file. 

Is there any way to turn off logging those Bro alerts via syslog? If
not, would we be missing any Bro alerts if we delete /var/log/messages?

Thanks!
Jaeyeon


From vern at icir.org  Tue Dec 28 00:08:50 2004
From: vern at icir.org (Vern Paxson)
Date: Tue, 28 Dec 2004 00:08:50 -0800
Subject: [Bro] problem of multi-interface monitor?
In-Reply-To: Your message of Thu, 23 Dec 2004 01:42:09 +0800.
Message-ID: <200412280808.iBS88oNn086592@jaguar.icir.org>

> when i execute "bro -i eth0 -i eth1 login.bro",bro only capture and deal
> with packets from eth0 and drop all from eth1.

I'm unable to reproduce this problem.  That is, I'm able to run Bro on
two interfaces and, regardless of the order of the two, it always sees
their traffic.

Are your two interfaces identical?  (Same link layer type, neither vlan'd.)

> "1103734623.487821:ContentGap:NOTICE_ALARM_ALWAYS::192.168.10.10:2422/tcp:192.168.10.77:23/tcp::::::192.168.10.10/2422         > 192.168.10.77/telnet content gap (> 69/11):"
>  
> after that,i emove "capture-filter ......" fom login.bro and try again,bro can capture and do rightly.

What does "do rightly" mean here?  That without the capture_filters in
login.bro, using both interfaces works correctly?

What happens if you trace each interface at the same time using
tcpdump -s 0, and then replay the traces using bro -r trace0 -r trace1 .... ?

		Vern


From bro-ids.org.hop at shendauer.com  Wed Dec 29 15:39:18 2004
From: bro-ids.org.hop at shendauer.com (Brian Lindauer)
Date: Wed, 29 Dec 2004 17:39:18 -0600
Subject: [Bro] Patch for gcc 3.4
Message-ID: <1104363559.2170.8.camel@localhost.localdomain>

I've made the attached changes locally to get bro to compile under gcc
3.4 with warnings turned all the way up.  I'm not suggesting that you
merge this patch directly into the code base, but it shows what areas
need to be addressed and will get bro to compile for anyone who just
wants to get it working.

Brian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: bro-gcc-3-4.patch
Type: text/x-patch
Size: 6883 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20041229/dc4acf46/attachment.bin 

From vern at icir.org  Wed Dec 29 23:46:17 2004
From: vern at icir.org (Vern Paxson)
Date: Wed, 29 Dec 2004 23:46:17 -0800
Subject: [Bro] Patch for gcc 3.4
In-Reply-To: Your message of Wed, 29 Dec 2004 17:39:18 CST.
Message-ID: <200412300746.iBU7kHh7016524@jaguar.icir.org>

Thanks for passing these along!  I don't see a problem with integrating
any of these (let me know if I'm missing something in this regard), so
will put them on the to-do list.

		Vern


From vern at icir.org  Thu Dec 30 02:38:47 2004
From: vern at icir.org (Vern Paxson)
Date: Thu, 30 Dec 2004 02:38:47 -0800
Subject: [Bro] How to turn off logging Bro alerts via syslog
In-Reply-To: Your message of Tue, 28 Dec 2004 02:11:16 EST.
Message-ID: <200412301038.iBUAcliD019517@jaguar.icir.org>

> We are running Bro 0.9a8.14 on our Linux system. We notice that
> / is often 100% full because of huge /var/log/messages, which
> seems filled with the Bro alerts that are also recorded in its 
> own alarm log file. 

You shouldn't be recording a huge number of alarms.  The philosophy is
that alarms should be of potential operator interest; while "notices" are
of general informational interest, but not something that should be
alarmed/syslog'd.  If you send me the alarms (privately) I can suggest
some ways to filter them down.

> would we be missing any Bro alerts if we delete /var/log/messages?

They'll still be recorded in alarm.$BRO_LOG_SUFFIX, but deleting
/var/log/messages is the wrong way to fix the problem!

		Vern


From bro-ids.org.hop at shendauer.com  Thu Dec 30 07:14:21 2004
From: bro-ids.org.hop at shendauer.com (Brian Lindauer)
Date: Thu, 30 Dec 2004 09:14:21 -0600
Subject: [Bro] Patch for gcc 3.4
In-Reply-To: <200412300746.iBU7kHh7016524@jaguar.icir.org>
References: <200412300746.iBU7kHh7016524@jaguar.icir.org>
Message-ID: <1104419661.2170.12.camel@localhost.localdomain>

On Wed, 2004-12-29 at 23:46 -0800, Vern Paxson wrote:
> Thanks for passing these along!  I don't see a problem with integrating
> any of these (let me know if I'm missing something in this regard), so
> will put them on the to-do list.

I mainly meant that you probably want to remove the commented-out
sections rather than merging in my ifdefs.  But I also think the 'friend
TCP_Connection' thing is a kind of a hack.  Someone more familiar with
the code could probably restructure it so that it's not necessary to get
a pointer to a protected parent class method.

Brian




From rpang at CS.Princeton.EDU  Thu Dec 30 10:53:31 2004
From: rpang at CS.Princeton.EDU (Ruoming Pang)
Date: Thu, 30 Dec 2004 10:53:31 -0800
Subject: [Bro] problem of multi-interface monitor?
In-Reply-To: <20041222174209.52728.qmail@web15508.mail.cnb.yahoo.com>
References: <20041222174209.52728.qmail@web15508.mail.cnb.yahoo.com>
Message-ID: <1951D573-5A94-11D9-8E05-000D9335A7D8@cs.princeton.edu>


On Dec 22, 2004, at 9:42 AM, ? ? wrote:

> Hello,
> when i execute "bro -i eth0 -i eth1 login.bro",bro only capture and  
> deal with packets from eth0 and drop all from eth1.
>  
> "1103734623.487821:ContentGap:NOTICE_ALARM_ALWAYS::192.168.10.10:2422/ 
> tcp:192.168.10.77:23/tcp::::::192.168.10.10/2422         >  
> 192.168.10.77/telnet content gap (> 69/11):"
>  
> after that,i emove "capture-filter ......" fom login.bro and try  
> again,bro can capture and do rightly.

What if you execute "bro -f '' ..." (which manually sets the filter to  
capture all packets)?

How about '-f "port telnet or tcp port 513"'?

Finally, without specifying the -f flag, what's the output if you print  
capture_filter in event bro_init()? Adding the following piece of code  
(to login.bro) will do:

event bro_init()
	{
	print fmt("%s", capture_filter);
	}

Ruoming
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1002 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20041230/e7c8e7fe/attachment.bin