From wli at CS.MsState.EDU  Tue Sep  4 18:54:35 2001
From: wli at CS.MsState.EDU (Wei Li)
Date: Tue, 4 Sep 2001 20:54:35 -0500
Subject: Attack example
Message-ID: <001b01c135ad$b7273960$39ce1282@pathfinder>

I am running Bro0.7a73 system in a single machine and preparing to carry out
some experiments.Who can explain the attack examples included in the Bro
packet?

BTW, are there some help documents available for Tcpdump and Bro? I mean
some fundemental aspects.

Thanks a lot.

-Wei Li




From postmaster at lbl.gov  Thu Sep  6 10:05:40 2001
From: postmaster at lbl.gov (postmaster at lbl.gov)
Date: Thu, 6 Sep 2001 10:05:40 -0700 (PDT)
Subject: Second Test--Please Ignore
Message-ID: <200109061705.f86H5dj28072@listserv.lbl.gov>

greetings.  sorry for the extra email.
you may safely delete this email.

bryce ryan, CITG, lawrence berkeley laboratory


From postmaster at lbl.gov  Thu Sep  6 11:03:22 2001
From: postmaster at lbl.gov (postmaster at lbl.gov)
Date: Thu, 6 Sep 2001 11:03:22 -0700 (PDT)
Subject: another test--please delete
Message-ID: <200109061803.f86I3MI22522@postal1.lbl.gov>

thanks...sorry for the extra

bryce ryan, CITG


From vern at ee.lbl.gov  Thu Sep  6 13:08:07 2001
From: vern at ee.lbl.gov (Vern Paxson)
Date: Thu, 06 Sep 2001 13:08:07 PDT
Subject: new Bro pre-release available - 0.7a90
Message-ID: <200109062008.f86K87313515@daffy.ee.lbl.gov>

A new Bro pre-release is now available from:

	ftp://ftp.ee.lbl.gov/.vp-bro-pub-0.7a90.tar.gz

The main theme of this release is better state management, especially for
use in high-volume sites.  There are now a number of ways to track the
resources consumed by Bro while it runs, and to reduce the amount of memory
Bro consumes.  Adding

	@load print-resources

will log a summary of the resources consumed by Bro when it exits, and

	@load reduce-memory

will change a number of default values in order to significantly diminish
the amount of memory Bro requires.

Other ways to lower the required memory:

	- The global "maintain_http_sessions" now controls whether
	  http.bro tracks multiple HTTP connections between the same
	  hosts as a single HTTP session.  Doing so costs a considerable
	  amount of state (so set to F for reducing the memory impact
	  of HTTP analysis).

	- The global "suppress_scan_checks", if true, turns off address
	  and port scan detection.  (You can't achieve this by simply
	  not @load'ing scan.bro, because it's loaded by some of the
	  default policy scripts.)  Turning it off can save a lot of memory.

	- Note, the ident.bro is also expensive in terms of state-holding.

A summary of other changes with respect to the last snapshot:

	- New library functions:

		- resource_usage() returns a record detailing real time,
		  CPU time, memory, other getrusage info, and the current
		  and maximum number of TCP/UDP/ICMP connections, and
		  timers and fragments.

		- val_size() returns the size in bytes needed to represent
		  a given value (which can be a record, a table, or a
		  simple constant, for example).  It's not fully accurate
		  but is in the right ballpark.

		- global_sizes() return a table mapping every global
		  variable to its size (per val_size()).  Useful for
		  tracking which ones are growing large over time.

	- You can now control a number of timers related to Bro's connection
	  management.  Setting them to lower values generally decreases the
	  amount of state Bro has to keep (see reduce-memory.bro), though
	  this can also make it easier for an attacker to evade detection:

		tcp_SYN_timeout: interval
			Controls how long Bro waits after seeing the
			beginning of a connection (whether due to a SYN
			or not; the timer is misnamed) before checking
			whether it elicited any reply.

		tcp_session_timer: interval
			After a connection has closed, wait this long for
			further activity before checking whether to time
			out its state.

		tcp_connection_linger: interval
			When checking a closed connection for further
			activity, Bro should consider it inactive if there
			hasn't been any for this long.  It also complains
			if the connection is reused before this much time
			has elapsed.

		tcp_attempt_delay: interval
			Bro waits this long upon seeing an initial SYN
			before timing out the connection attempt.

		tcp_close_delay: interval
			Upon seeing a normal connection close, Bro flushes
			state after this much time.

		tcp_reset_delay: interval
			Upon seeing a RST, Bro flushes state after this
			much time.

		tcp_partial_close_delay: interval
			Bro generates a connection_partial_close event this
			much time after one half of a partial connection
			closes, assuming there has been no subsequent
			activity.

		non_analyzed_lifetime: interval
			If a connection belongs to an application that you
			aren't analyzing, Bro times it out after this
			interval.  If 0 secs (default), then it doesn't
			time it out.

		dns_session_timeout: interval
		ntp_session_timeout: interval
		rpc_timeout: interval
			Bro waits this long before timing out a DNS/NTP/RPC
			request.

		max_timer_expires: count
			The maximum number of timers to expire after
			processing each new packet.  The value trades off
			spreading out the timer expiration load with
			possibly having to hold state longer.  A value of 0
			means "process all expired timers with each new
			packet".

	- Two new flags control other facets of Bro's connection management,
	  and thus state-holding:

		partial_connection_ok: bool
			Whether Bro should analyze connections for which
			it doesn't see the beginning, only the middle.
			This can be very expensive to do in the face of
			stealth-scanning, which looks like a bunch of
			partial connections.

			Note, the HTTP analyzer has been modified to
			now always skip partial connections.  This should
			instead be user controllable.

		tcp_SYN_ack_ok: bool
			If true, Bro instantiates connection state when
			it sees a SYN ack but not the initial SYN (even
			if partial_connection_ok is false).  The intent
			behind this knob (which is not well tested) is
			to allow you to filter out initial SYNs and only
			react to SYN acks.  This keeps Bro from holding
			state during SYN scans and SYN flooding, except
			for when the destination responds.

	- Some other miscellaneous thresholds that you can now modify
	  from your policy script:

		heartbeat_interval: count
			How often to generate net_stats_update() events.
			This timer really isn't needed any more, since
			you can use "schedule" to achieve the same effect.

		tcp_storm_thresh: count
			If Bro sees this many FINs/RSTs in a row, it
			flags them as a "storm".

		tcp_storm_interarrival_thresh: interval
			The FINs/RSTs must come with this much time or less
			between them.

	- The state management for line-oriented applications like HTTP
	  requests has been improved.

	- The HTTP analyzer now expands %hex sequences.  If anyone has
	  a Unicode expander to contribute, that'd be terrific.

	- The Code Red detection is more robust (fewer false positives).

	- A new redefinable variable, skip_services, lists applications
	  that should not be analyzed for purposes of detecting scans.
	  (Default: ident)  The point of having this (poorly named) hook
	  is so that code-red.bro can add "http" to it, to avoid reporting
	  the zillions of Code Red scans that a site can see.

	- Bro now matches regular expressions using lazy DFA evaluation.
	  The upshot of this is (1) it no longer maintains .bro-RE-cache.v1,
	  (2) it starts up fast regardless of whether you've added new
	  regular expressions, (3) you can afford to add lots of regular
	  expressions, and (4) it's actually a bit faster.
 
	- The list of "hot_ids" has been expanded with a number of other
	  common root-privileged accounts.

- Vern


From vern at ee.lbl.gov  Thu Sep  6 13:13:02 2001
From: vern at ee.lbl.gov (Vern Paxson)
Date: Thu, 06 Sep 2001 13:13:02 PDT
Subject: Attack example
In-Reply-To: Your message of Tue, 04 Sep 2001 20:54:35 PDT.
Message-ID: <200109062013.f86KD2t13646@daffy.ee.lbl.gov>

> I am running Bro0.7a73 system in a single machine and preparing to carry out
> some experiments.Who can explain the attack examples included in the Bro
> packet?

I'm not sure what you're asking here.  One of them is a trace of an
FTP "site exec" attack, the other of an NTP overflow attack.

> BTW, are there some help documents available for Tcpdump and Bro? I mean
> some fundemental aspects.

For tcpdump, only "man tcpdump".  For Bro, see the doc/ subdirectory.

		Vern


From jdugan at ncsa.uiuc.edu  Thu Sep  6 17:10:22 2001
From: jdugan at ncsa.uiuc.edu (Jon Dugan)
Date: Thu, 6 Sep 2001 19:10:22 -0500
Subject: expression rejects all packets
Message-ID: <20010906191022.A32686@ncsa.uiuc.edu>


  When I start up bro, I get the following message:

  #./bro -i sk0 -i sk1 mt ncsa
  listening on sk0
  ./bro: problem with interface sk1 - pcap_compile((vlan) and (((((((((ip[6:2] &
  0x3fff != 0) and tcp) or (tcp[13] & 0x7 != 0)) or (port finger)) or (tcp port
  113)) or (port ftp)) or (port telnet or tcp port 513)) or (port 111)) or (udp
  port 123))): expression rejects all packets

  the contents of ncsa.bro are:

    redef restrict_filter = "vlan";

  it's weird it looks like the pcap expression compiles for one interface but
  not the second.

  the link i am running bro on uses 802.1Q VLAN tagging, which are supported
  by recent versions of libpcap.  (well, mostly supported, you can either look
  at tagged frames or frames on the native VLAN, but not both at the same time
  -- because of the way libpcap handles the VLAN tags internally.  for my
  purposes i don't need to look at the native VLAN since there is no traffic
  on it.)

  in order to get this far i had to rearrange the order of capture_f and
  restrict_f in main.cc, i put restrict on the left and capture on the left.
  without doing that the expression wouldn't compile the pcap expression for
  the first interface.

  any suggestions?

  thanks,

Jon
-- 
Jon Dugan             |  Senior Network Engineer, NCSA Network Development
jdugan at ncsa.uiuc.edu  |  269 CAB, 605 E Springfield, Champaign, IL 61820
217-244-7715          |  http://www.ncsa.uiuc.edu/people/jdugan


From vern at ee.lbl.gov  Thu Sep  6 17:23:46 2001
From: vern at ee.lbl.gov (Vern Paxson)
Date: Thu, 06 Sep 2001 17:23:46 PDT
Subject: expression rejects all packets
In-Reply-To: Your message of Thu, 06 Sep 2001 19:10:22 PDT.
Message-ID: <200109070023.f870NkX15049@daffy.ee.lbl.gov>

>   #./bro -i sk0 -i sk1 mt ncsa
>   listening on sk0
>   ./bro: problem with interface sk1 - pcap_compile((vlan) and (((((((((ip[6:2] &
>   0x3fff != 0) and tcp) or (tcp[13] & 0x7 != 0)) or (port finger)) or (tcp port
>   113)) or (port ftp)) or (port telnet or tcp port 513)) or (port 111)) or (udp
>   port 123))): expression rejects all packets
> 
>   the contents of ncsa.bro are:
> 
>     redef restrict_filter = "vlan";
> 
>   it's weird it looks like the pcap expression compiles for one interface but
>   not the second.

First thing to try is feeding the expression manually to tcpdump for each
of the interfaces, to see whether you get the same message.

I suspect the problem is that "vlan" expands into something equates with
"not ip", and so the conjunction is always false, since all of the other
expressions require "ip" to be true.  I'm not sure how to fix this, as
my version of tcpdump/libpcap doesn't know about "vlan".

>   for my
>   purposes i don't need to look at the native VLAN since there is no traffic
>   on it.)

Then wouldn't your filter be "not vlan" rather than "vlan"?

>   in order to get this far i had to rearrange the order of capture_f and
>   restrict_f in main.cc, i put restrict on the left and capture on the left.
>   without doing that the expression wouldn't compile the pcap expression for
>   the first interface.

That doesn't sound good - they're just a conjunction together, so pcap
should compile them in either order.  I wonder if "vlan" is implemented
inside pcap as some sort of hack ...

		Vern


From jdugan at ncsa.uiuc.edu  Thu Sep  6 17:54:30 2001
From: jdugan at ncsa.uiuc.edu (Jon Dugan)
Date: Thu, 6 Sep 2001 19:54:30 -0500
Subject: expression rejects all packets
In-Reply-To: <200109070023.f870NkX15049@daffy.ee.lbl.gov>; from vern@ee.lbl.gov on Thu, Sep 06, 2001 at 05:23:46PM -0700
Message-ID: <20010906195430.A33242@ncsa.uiuc.edu>

On Thu, Sep 06, 2001 at 05:23:46PM -0700, Vern Paxson wrote:
> >   #./bro -i sk0 -i sk1 mt ncsa
> >   listening on sk0
> >   ./bro: problem with interface sk1 - pcap_compile((vlan) and (((((((((ip[6:2] &
> >   0x3fff != 0) and tcp) or (tcp[13] & 0x7 != 0)) or (port finger)) or (tcp port
> >   113)) or (port ftp)) or (port telnet or tcp port 513)) or (port 111)) or (udp
> >   port 123))): expression rejects all packets
> > 
> >   the contents of ncsa.bro are:
> > 
> >     redef restrict_filter = "vlan";
> > 
> >   it's weird it looks like the pcap expression compiles for one interface but
> >   not the second.
> 
> First thing to try is feeding the expression manually to tcpdump for each
> of the interfaces, to see whether you get the same message.

  Ok.  I did that and it worked on each interface.

> I suspect the problem is that "vlan" expands into something equates with
> "not ip", and so the conjunction is always false, since all of the other
> expressions require "ip" to be true.  I'm not sure how to fix this, as
> my version of tcpdump/libpcap doesn't know about "vlan".

  It's in the version of libpcap available from tcpdump.org.  I think it may
  have been merged into the version that ships with FreeBSD 4.4-RELEASE.

  Actually it just moves the beginning of packet pointer to the right 4 bytes
  -- it assumes that a frames on the wire are tagged.

  Here's the relevant paragraph from the tcpdump manpage:

              vlan [vlan_id]
                     True  if  the  packet is an IEEE 802.1Q VLAN
                     packet.  If  [vlan_id]  is  specified,  only
                     true   is   the  packet  has  the  specified
                     vlan_id.  Note that the first  vlan  keyword
                     encountered in expression changes the decod-
                     ing offsets for the remainder of  expression
                     on  the assumption that the packet is a VLAN
                     packet.

> >   for my
> >   purposes i don't need to look at the native VLAN since there is no traffic
> >   on it.)
> 
> Then wouldn't your filter be "not vlan" rather than "vlan"?

  No, the vlan with no arguments simply moves the pointer to skip the tags.

> >   in order to get this far i had to rearrange the order of capture_f and
> >   restrict_f in main.cc, i put restrict on the left and capture on the left.
> >   without doing that the expression wouldn't compile the pcap expression for
> >   the first interface.
> 
> That doesn't sound good - they're just a conjunction together, so pcap
> should compile them in either order.  I wonder if "vlan" is implemented
> inside pcap as some sort of hack ...

  That's what I was thinking.

  I've been working on patches to improve the way VLANs are supported in
  libpcap -- however the additional BPF logic i added to the statements that
  libpcap generates seems to confuse the optimizer in libpcap.

Jon
-- 
Jon Dugan             |  Senior Network Engineer, NCSA Network Development
jdugan at ncsa.uiuc.edu  |  269 CAB, 605 E Springfield, Champaign, IL 61820
217-244-7715          |  http://www.ncsa.uiuc.edu/people/jdugan


From root at lbl.gov  Fri Sep  7 00:21:18 2001
From: root at lbl.gov (Super-User)
Date: Fri, 7 Sep 2001 00:21:18 -0700 (PDT)
Subject: No subject
Message-ID: <200109070721.f877LIl16176@postal1.lbl.gov>



From vern at ee.lbl.gov  Fri Sep  7 00:37:54 2001
From: vern at ee.lbl.gov (Vern Paxson)
Date: Fri, 07 Sep 2001 00:37:54 PDT
Subject: expression rejects all packets
In-Reply-To: Your message of Thu, 06 Sep 2001 19:54:30 PDT.
Message-ID: <200109070737.f877bsh17815@daffy.ee.lbl.gov>

I've discussed this with Bill Fenner (who's our primary contact for the
tcpdump.org development since we handed over the source tree to them).
He confirmed that there's a bug in using "vlan" for multiple interfaces;
I'm not sure if/when a fix will be forthcoming.

		Vern


From pid21_21 at yahoo.com  Tue Sep 11 21:39:35 2001
From: pid21_21 at yahoo.com (Chaivat Jirapummin)
Date: Tue, 11 Sep 2001 21:39:35 -0700 (PDT)
Subject: File Input Format
Message-ID: <20010912043935.78454.qmail@web10607.mail.yahoo.com>

Dear all,
      I just  used Bro recently. I have question about
using bro as off-line detector. The input file was
read by
bro -r filename
     According to the manual, the input file has to be
TCPdump format. I used the Information Exploration
Shootout database, but it didnot be read. The error
message "Improper format dump file"  appeared on the
screen. For input file format,

Time Src.Srcport > Dst.Dstport  Flag Seq1:Seq2 Ack Win
Buf Opt

How can Bro read this data? Can it read the CSV
format?
Thankyou.

Chaivat J.





__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com


From athomas at unity.ncsu.edu  Wed Sep 12 12:21:39 2001
From: athomas at unity.ncsu.edu (Ashley Thomas)
Date: Wed, 12 Sep 2001 15:21:39 -0400
Subject: File Input Format
References: <20010912043935.78454.qmail@web10607.mail.yahoo.com>
Message-ID: <3B9FB5C3.E3294CEF@unity.ncsu.edu>

Bro needs the tcpdump file in 'raw' format. ie the kind of file you get when
you use tcpdump with -w option.

cheers
ashley

Chaivat Jirapummin wrote:

> Dear all,
>       I just  used Bro recently. I have question about
> using bro as off-line detector. The input file was
> read by
> bro -r filename
>      According to the manual, the input file has to be
> TCPdump format. I used the Information Exploration
> Shootout database, but it didnot be read. The error
> message "Improper format dump file"  appeared on the
> screen. For input file format,
>
> Time Src.Srcport > Dst.Dstport  Flag Seq1:Seq2 Ack Win
> Buf Opt
>
> How can Bro read this data? Can it read the CSV
> format?
> Thankyou.
>
> Chaivat J.
>
> __________________________________________________
> Do You Yahoo!?
> Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
> http://im.yahoo.com



From jdugan at ncsa.uiuc.edu  Wed Sep 12 17:01:00 2001
From: jdugan at ncsa.uiuc.edu (Jon Dugan)
Date: Wed, 12 Sep 2001 19:01:00 -0500
Subject: expression rejects all packets
In-Reply-To: <200109070737.f877bsh17815@daffy.ee.lbl.gov>; from vern@ee.lbl.gov on Fri, Sep 07, 2001 at 12:37:54AM -0700
Message-ID: <20010912190100.A61555@ncsa.uiuc.edu>

  Any ideas where to look?  I'd be happy to give it a shot (and will take a
  look).

On Fri, Sep 07, 2001 at 12:37:54AM -0700, Vern Paxson wrote:
> I've discussed this with Bill Fenner (who's our primary contact for the
> tcpdump.org development since we handed over the source tree to them).
> He confirmed that there's a bug in using "vlan" for multiple interfaces;
> I'm not sure if/when a fix will be forthcoming.
> 
> 		Vern

  Thanks,

Jon
-- 
Jon Dugan             |  Senior Network Engineer, NCSA Network Development
jdugan at ncsa.uiuc.edu  |  269 CAB, 605 E Springfield, Champaign, IL 61820
217-244-7715          |  http://www.ncsa.uiuc.edu/people/jdugan


From fenner at research.att.com  Wed Sep 12 18:33:50 2001
From: fenner at research.att.com (Bill Fenner)
Date: Wed, 12 Sep 2001 18:33:50 -0700
Subject: expression rejects all packets
Message-ID: <200109130133.SAA14015@windsor.research.att.com>


I'm still not 100% clear what the problem is.  pcap_compile()
resets the off_linktype and off_nl fields before compiling the
expression, so a "vlan" qualifier in an earlier expression can't
affect future calls to pcap_compile().  Multiple "vlan" qualifiers
in the same expression set the offsets to the same constant
offset.

The only bug I'm aware of is that the "vlan" qualifier is positional
and so affects all expressions after it, so if you use the expression
"( vlan and ip ) or ip" (trying to match non-trunked IP packets as well as
VLAN-trunked) you end up getting just trunked packets; you need to use
"ip or ( vlan and ip )".

Actually, I take it back -- after composing this email, I decided to
double-check the compiler, and there's an optimizer bug that affects
the first construct I described:

mango% ./xprtest vlan and ip or ip
(000) ldh      [12]
(001) ldh      [16]
(002) jeq      #0x800           jt 3    jf 4
(003) ret      #96
(004) ret      #0

Disabling the optimizer results in a correct (but redundant) expression.
Perhaps you're running into something like this?

  Bill


From fenner at research.att.com  Wed Sep 12 20:23:08 2001
From: fenner at research.att.com (Bill Fenner)
Date: Wed, 12 Sep 2001 20:23:08 -0700
Subject: expression rejects all packets
Message-ID: <200109130323.UAA15580@windsor.research.att.com>


I take it back; I do know what's going on after all.  The problem is that
gen_vlan() has a static variable that remembers whether it has adjusted
the offsets for the VLAN header yet; this static variable doesn't get
reset on the second pcap_compile() so the offset doesn't get adjusted
the second time around, so this is like "ether type 0x8100 and ether
type 0x800", which is why it optimizes to "reject all".

I'll see if I can come up with a fix.

  Bill


From trinhtuan at hn.vnn.vn  Mon Sep 17 09:33:18 2001
From: trinhtuan at hn.vnn.vn (Trinh Anh Tuan)
Date: Mon, 17 Sep 2001 23:33:18 +0700
Subject: Question on discarder_* functions in version 7a90
Message-ID: <002101c13f96$e3c88c60$081a19ac@boby.cfti.edu.vn>

Hello,

I've gotten the new version of bro, there're some changes but the most curious change is a serie of discarder_* functions and their input type *_hdr. Could you draw some hints on their usages?

Many Thanks.

Cordially,
---------------------------------------------------------------------------
Trinh Anh Tuan  -  CMO-CFTI/NACENTECH
Ministry of Science, Technologies and Environment
Off. Tel.: (84-4) 8541197 - Off. Fax: (84-4) 8548187
Handphone: (84) 913-323266
---------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20010917/45ed4e6e/attachment.html 

From vern at aciri.org  Tue Sep 18 10:13:37 2001
From: vern at aciri.org (Vern Paxson)
Date: Tue, 18 Sep 2001 10:13:37 -0700
Subject: update to code-red.bro to detect today's new worm
Message-ID: <200109181713.f8IHDbH33230@yak.aciri.org>

The appended version calls it "Code Red type 3", though that's a misnomer.
However, I thought I should get this out pronto and worry about getting
the name right later.

		Vern


@load site

# Change these initializations to correspond to your own /16 and /24 nets.
# redef local_16_nets = { 128.3.0.0, 131.243.0.0, };
# redef local_24_nets = { 1.2.3.0, };

redef capture_filter += "tcp dst port 80";

# redef sensitive_URIs += /root\.exe/;

global code_red_log = open_log_file("code-red") &redef;
global code_red_list1: table[addr] of count &default=0;
global code_red_list2: table[addr] of count &default=0;
global code_red_list3: table[addr] of count &default=0;

# If you define the following to a non-empty value, then they will be
# invoked for the first instances of confirmed local/remote Code Red
# infections.
global local_code_red_response_pgm = "" &redef;
global remote_code_red_response_pgm = "" &redef;

event http_request(c: connection, request: string, URI: string)
	{
	if ( /(\.id[aq]\?.*(NNNNNNNNNNNNN|XXXXXXXXXXXXX))|(\/scripts\/root\.exe\?\/c\+tftp)/ in URI )
		{
		local id = c$id;
		local src = id$orig_h;
		local is_local = is_local_addr(src);
		local where = is_local ? "local" : "remote";
		local live = reading_live_traffic();

		# The following will be 1/2/3 for the first time we
		# see a given local/remote host exhibit type I, II, III
		local new_CR_type = 0;

		if ( /NNNNNNNNNNNNN/ in URI )
			{
			if ( ++code_red_list1[src] == 1 )
				new_CR_type = 1;
			}

		else if ( /XXXXXXXXXXXXX/ in URI )
			{
			if ( ++code_red_list2[src] == 1 )
				new_CR_type = 2;
			}

		else
			{
			if ( ++code_red_list3[src] == 1 )
				new_CR_type = 3;
			}

		if ( new_CR_type != 0 )
			{
			# First time we've seen it.

			if ( is_local )
				{
				log fmt("local Code Red %d worm source: %s",
					new_CR_type, src);

				if ( live && local_code_red_response_pgm != "" )
					system(fmt("%s %s",
						local_code_red_response_pgm,
						src));
				}

			else
				if ( live && remote_code_red_response_pgm != "" )
					system(fmt("%s %s",
						remote_code_red_response_pgm,
						src));

			print code_red_log,
				fmt("%.6f %s Code Red %d worm source: %s",
					network_time(),
					where, new_CR_type, src);
			}
		}

	else if ( /default\.ida..../ in URI )
		print code_red_log,
			fmt("%.6f unknown default.ida probe from: %s (%s)",
				network_time(), src, URI);
	}

# Ignore "weird" events, we get some due to the capture_filter above that
# only captures the client side of an HTTP session.
event conn_weird(name: string, c: connection)
	{
	}


From vern at aciri.org  Tue Sep 18 16:44:09 2001
From: vern at aciri.org (Vern Paxson)
Date: Tue, 18 Sep 2001 16:44:09 -0700
Subject: update to code-red.bro to detect today's new worm 
In-Reply-To: Your message of Tue, 18 Sep 2001 10:13:37 PDT.
Message-ID: <200109182344.f8INi9H43936@yak.aciri.org>

Here's a revision that has a somewhat better detector.

		Vern


@load site

# Change these initializations to correspond to your own /16 and /24 nets.
# redef local_16_nets = { 128.3.0.0, 131.243.0.0, };
# redef local_24_nets = { 1.2.3.0, };

redef capture_filter += "tcp dst port 80";

# redef sensitive_URIs += /root\.exe/;

global code_red_log = open_log_file("code-red") &redef;
global code_red_list1: table[addr] of count &default=0;
global code_red_list2: table[addr] of count &default=0;
global code_red_list3: table[addr] of count &default=0;

# If you define the following to a non-empty value, then they will be
# invoked for the first instances of confirmed local/remote Code Red
# infections.
global local_code_red_response_pgm = "" &redef;
global remote_code_red_response_pgm = "" &redef;

event http_request(c: connection, request: string, URI: string)
	{
	if ( /(\.id[aq]\?.*(NNNNNNNNNNNNN|XXXXXXXXXXXXX))|(\/scripts\/root\.exe\?\/c\+tftp|\/MSADC\/root.exe\?\/c\+dir)/ in URI )
		{
		local id = c$id;
		local src = id$orig_h;
		local is_local = is_local_addr(src);
		local where = is_local ? "local" : "remote";
		local live = reading_live_traffic();

		# The following will be 1/2/3 for the first time we
		# see a given local/remote host exhibit type I, II, III
		local new_CR_type = 0;

		if ( /NNNNNNNNNNNNN/ in URI )
			{
			if ( ++code_red_list1[src] == 1 )
				new_CR_type = 1;
			}

		else if ( /XXXXXXXXXXXXX/ in URI )
			{
			if ( ++code_red_list2[src] == 1 )
				new_CR_type = 2;
			}

		else
			{
			if ( ++code_red_list3[src] == 1 )
				new_CR_type = 3;
			}

		if ( new_CR_type != 0 )
			{
			# First time we've seen it.

			if ( is_local )
				{
				log fmt("local Code Red %d worm source: %s",
					new_CR_type, src);

				if ( live && local_code_red_response_pgm != "" )
					system(fmt("%s %s",
						local_code_red_response_pgm,
						src));
				}

			else
				if ( live && remote_code_red_response_pgm != "" )
					system(fmt("%s %s",
						remote_code_red_response_pgm,
						src));

			print code_red_log,
				fmt("%.6f %s Code Red %d worm source: %s",
					network_time(),
					where, new_CR_type, src);
			}
		}

	else if ( /default\.ida..../ in URI )
		print code_red_log,
			fmt("%.6f unknown default.ida probe from: %s (%s)",
				network_time(), src, URI);
	}

# Ignore "weird" events, we get some due to the capture_filter above that
# only captures the client side of an HTTP session.
event conn_weird(name: string, c: connection)
	{
	}


From vern at aciri.org  Wed Sep 19 23:09:03 2001
From: vern at aciri.org (Vern Paxson)
Date: Wed, 19 Sep 2001 23:09:03 -0700
Subject: Question on discarder_* functions in version 7a90 
In-Reply-To: Your message of Mon, 17 Sep 2001 23:33:18 +0700.
Message-ID: <200109200609.f8K693H76379@yak.aciri.org>

> I've gotten the new version of bro, there're some changes but the most =
> curious change is a serie of discarder_* functions and their input type =
> *_hdr. Could you draw some hints on their usages?

These are functions that, if you define them, are called on a per-packet
basis.  Your function needs to return either T, indicating that the packet
should be discarded and not processed further, or F, indicating that the
packet should be kept.

Discarders are basically a hack introduced to facilitate some of the
stepping-stone analysis (you can use them to trim a large trace file down
to a subset, where the definition of the subset is too complicated to fit
into a tcpdump filter, but can easily fit into a Bro table that the
discarder function consults).  They provide quite-general, but not very
efficient, functionality.

		Vern


From athomas at unity.ncsu.edu  Wed Sep 26 17:13:52 2001
From: athomas at unity.ncsu.edu (Ashley Thomas)
Date: Wed, 26 Sep 2001 20:13:52 -0400
Subject: Link error
Message-ID: <3BB26F40.4CFC83F4@unity.ncsu.edu>

Hi,

I have 2 versions of bro-pub-0.7a48 (with only difference in policies)
When i do a  '.configure' and then a make on one of them (in the
corresponding directory) , it works fine.

For the next, i do the same for the second(.configure and make in its
directory), it gives:

parse.o: Definition of symbol `_yylhs' (multiply defined)
parse.o: Definition of symbol `_yylen' (multiply defined)
parse.o: Definition of symbol `_yydefred' (multiply defined)
parse.o: Definition of symbol `_yydgoto' (multiply defined)
parse.o: Definition of symbol `_yysindex' (multiply defined)
parse.o: Definition of symbol `_yyrindex' (multiply defined)
parse.o: Definition of symbol `_yygindex' (multiply defined)
parse.o: Definition of symbol `_yytable' (multiply defined)
parse.o: Definition of symbol `_yycheck' (multiply defined)
../libpcap-0.6.2/libpcap.a(grammar.o): Definition of symbol `_yylhs'
(multiply defined)
../libpcap-0.6.2/libpcap.a(grammar.o): Definition of symbol `_yylen'
(multiply defined)
../libpcap-0.6.2/libpcap.a(grammar.o): Definition of symbol `_yydefred'
(multiply defined)
../libpcap-0.6.2/libpcap.a(grammar.o): Definition of symbol `_yydgoto'
(multiply defined)
../libpcap-0.6.2/libpcap.a(grammar.o): Definition of symbol `_yysindex'
(multiply defined)
../libpcap-0.6.2/libpcap.a(grammar.o): Definition of symbol `_yyrindex'
(multiply defined)
../libpcap-0.6.2/libpcap.a(grammar.o): Definition of symbol `_yygindex'
(multiply defined)
../libpcap-0.6.2/libpcap.a(grammar.o): Definition of symbol `_yytable'
(multiply defined)
../libpcap-0.6.2/libpcap.a(grammar.o): Definition of symbol `_yycheck'
(multiply defined)
collect2: ld returned 1 exit status
*** Error code 1

I am using the same libpcap-0.6.2 for both.

I can't figure out what is wrong with one which is not with the other ?

thanks a lot
Ashley





From vern at aciri.org  Wed Sep 26 19:01:34 2001
From: vern at aciri.org (Vern Paxson)
Date: Wed, 26 Sep 2001 19:01:34 -0700
Subject: Link error 
In-Reply-To: Your message of Wed, 26 Sep 2001 20:13:52 EDT.
Message-ID: <200109270201.f8R21YH13531@yak.aciri.org>

> parse.o: Definition of symbol `_yylhs' (multiply defined)
> ../libpcap-0.6.2/libpcap.a(grammar.o): Definition of symbol `_yylhs'

Looks like Bro got built using a version of yacc that doesn't support -p,
while presumably the other version of Bro was built with a version of
yacc that does.

		Vern


From athomas at unity.ncsu.edu  Thu Sep 27 19:38:42 2001
From: athomas at unity.ncsu.edu (Ashley Thomas)
Date: Thu, 27 Sep 2001 22:38:42 -0400
Subject: Bro: a question regarding type
Message-ID: <3BB3E2B2.BAE97837@unity.ncsu.edu>

Hi,

I had a general question regarding Bro.
Can we classify it under Rule based or Anomaly based as usually IDSs are
classified ?
I would guess it is a Rule based one. Is there any anomaly detection in
Bro ?

When it is stated that an IDS can withstand upto or greater than 'X'
Mbps,
do we make any assumptions regarding the number of rules in the
rule-based IDS ?
I would think as the rules increases, the traffic that the IDS can
withstand should decrease.

thanks a lot
Ashley





From athomas at unity.ncsu.edu  Sat Sep 29 23:24:15 2001
From: athomas at unity.ncsu.edu (Ashley Thomas)
Date: Sun, 30 Sep 2001 02:24:15 -0400
Subject: Traffic generator
References: <200109270201.f8R21YH13531@yak.aciri.org>
Message-ID: <3BB6BA8F.A2EA8A5C@unity.ncsu.edu>

Hi ,

Could you suggest a freely available tool to generate traffic on the network
for
measuring IDS's behaviour. It would be great if the tool can generate a
variety of
traffic and bursty/continuous behaviour.

thanks
Ashley