From dhanesh at tataelxsi.co.in Thu Oct 5 22:29:22 2006 From: dhanesh at tataelxsi.co.in (Jaya Dhanesh) Date: Fri, 6 Oct 2006 10:59:22 +0530 Subject: [Bro] Writing Analyzers In-Reply-To: <20060929184119.GF29116@icir.org> Message-ID: <000201c6e908$619b0f80$0637a8c0@telxsi.com> Hi, When writing an Analyzer for a protocol, say X that runs on top of TCP connection, should I always include the 'Deliver' function. Is it the function that gets called every time a X packet arrives at the interface? Thanks, Dhanesh. From mchristensen at packetmotion.com Fri Oct 6 07:20:24 2006 From: mchristensen at packetmotion.com (Mitchell Christensen) Date: Fri, 6 Oct 2006 07:20:24 -0700 Subject: [Bro] Bro 1.2 source code Message-ID: Hey, I'm evaluating binpac as described in the ACM paper and notice that some of the features described in the paper don't seem to exist in the 1.1 code release. I can't find a link to the 1.2 source code anywhere. Does 1.1 represent the tip of the development branch? Is the 1.2 Bro source code available? If not, is there a schedule for when it will become available? -Mitch Christensen From vern at icir.org Fri Oct 6 07:43:14 2006 From: vern at icir.org (Vern Paxson) Date: Fri, 06 Oct 2006 07:43:14 -0700 Subject: [Bro] Bro 1.2 source code In-Reply-To: (Fri, 06 Oct 2006 07:20:24 PDT). Message-ID: <200610061443.k96EhEaT001883@jaguar.icir.org> We'll be releasing 1.2 quite soon. In fact, we had expected it to be out already, but found some bugs during final testing that have taken a while to iron out. Vern From robin at icir.org Fri Oct 6 09:17:18 2006 From: robin at icir.org (Robin Sommer) Date: Fri, 6 Oct 2006 09:17:18 -0700 Subject: [Bro] Writing Analyzers In-Reply-To: <000201c6e908$619b0f80$0637a8c0@telxsi.com> References: <20060929184119.GF29116@icir.org> <000201c6e908$619b0f80$0637a8c0@telxsi.com> Message-ID: <20061006161718.GA16286@icir.org> On Fri, Oct 06, 2006 at 10:59 +0530, you wrote: > When writing an Analyzer for a protocol, say X that runs on top of > TCP connection, should I always include the 'Deliver' function. Is it the > function that gets called every time a X packet arrives at the interface? Please note that the analyzer interface is going to change quite a bit with the upcoming 1.2 release (real soon now :-), and I recommend to use new API for any new code. There is actually already some documentation available for it in the Bro Wiki (see "API for dynamic protocol detection"). That said, for a TCP-based analyzer you most probably don't want to work on packets but on the reassembled payload stream. With the new API, TCP_ApplicationAnalyzer::DeliverStream() is the entry point for that. Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org LBNL/ICSI * Fax +1 (510) 666-2956 * www.icir.org From sanreich at gmx.de Fri Oct 6 11:00:07 2006 From: sanreich at gmx.de (Sandro Reichert) Date: Fri, 06 Oct 2006 20:00:07 +0200 Subject: [Bro] remote.bro In-Reply-To: <451C1B33.1020207@gmx.de> References: <451C1B33.1020207@gmx.de> Message-ID: <452699A7.30701@gmx.de> thanks for the hints, inter-bro(1.1) communication works :-) but - it only works with traffic on the listening interface - is that right? i dont have a network trap or something like this, my configuration for testing is: 2 PCs with 1 eth interface connected to a switch. when i start both bros, there is nothing written into the remote-logs until i start a port-scan to generate traffic. what would be the best way to generate dummy traffic ? Thanks, Sandro From christian at whoop.org Fri Oct 6 12:09:40 2006 From: christian at whoop.org (Christian Kreibich) Date: Fri, 06 Oct 2006 12:09:40 -0700 Subject: [Bro] remote.bro In-Reply-To: <452699A7.30701@gmx.de> References: <451C1B33.1020207@gmx.de> <452699A7.30701@gmx.de> Message-ID: <1160161780.20440.27.camel@strangepork> Hi Sandro, On Fri, 2006-10-06 at 20:00 +0200, Sandro Reichert wrote: > thanks for the hints, inter-bro(1.1) communication works :-) great! :) > but - it only works with traffic on the listening interface - is that > right? i dont have a network trap or something like this, my > configuration for testing is: > 2 PCs with 1 eth interface connected to a switch. > when i start both bros, there is nothing written into the remote-logs > until i start a port-scan to generate traffic. what would be the best > way to generate dummy traffic ? Mhmmm this is not supposed to happen any more -- older versions did indeed have the problem that communication was "driven" by observing live traffic, but as of 1.1 this should be fixed. Things depend on whether your OS supports selectable file descriptors or not. Could you please tell us what OS you are on, and post (or send me) the config.h file you obtain after running configure? Thanks. Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From sanreich at gmx.de Sat Oct 7 10:21:00 2006 From: sanreich at gmx.de (Sandro Reichert) Date: Sat, 07 Oct 2006 19:21:00 +0200 Subject: [Bro] remote.bro In-Reply-To: <1160161780.20440.27.camel@strangepork> References: <451C1B33.1020207@gmx.de> <452699A7.30701@gmx.de> <1160161780.20440.27.camel@strangepork> Message-ID: <4527E1FC.5060606@gmx.de> Hi Christian, >> but - it only works with traffic on the listening interface - is that >> right? i dont have a network trap or something like this, my >> configuration for testing is: >> 2 PCs with 1 eth interface connected to a switch. >> when i start both bros, there is nothing written into the remote-logs >> until i start a port-scan to generate traffic. what would be the best >> way to generate dummy traffic ? > > Mhmmm this is not supposed to happen any more -- older versions did > indeed have the problem that communication was "driven" by observing > live traffic, but as of 1.1 this should be fixed. Things depend on > whether your OS supports selectable file descriptors or not. Could you > please tell us what OS you are on, and post (or send me) the config.h > file you obtain after running configure? Thanks. Im using Suse 10.0 on both machines. One Bro1.1 runs on PC 'A', the other on PC 'B' runs on VMware Server, because I started testing with our wireless 0.9a9 edition and we havnt finished the wireless patch for 1.1 yet. It should be done within the next days. A: Suse 10.0 & Bro 1.1 B: Suse 10.0 & "Bro-wireless" 0.9a9 VMware: Suse 10.0 Bro 1.1 The config.h are equal on both machines. bye, Sandro -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config.h Url: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20061007/2042b302/attachment.h From christian at whoop.org Sat Oct 7 21:33:20 2006 From: christian at whoop.org (Christian Kreibich) Date: Sat, 07 Oct 2006 21:33:20 -0700 Subject: [Bro] remote.bro In-Reply-To: <4527E1FC.5060606@gmx.de> References: <451C1B33.1020207@gmx.de> <452699A7.30701@gmx.de> <1160161780.20440.27.camel@strangepork> <4527E1FC.5060606@gmx.de> Message-ID: <1160282001.20440.101.camel@strangepork> Hi Sandro, On Sat, 2006-10-07 at 19:21 +0200, Sandro Reichert wrote: > Hi Christian, > > Im using Suse 10.0 on both machines. One Bro1.1 runs on PC 'A', the > other on PC 'B' runs on VMware Server, because I started testing with > our wireless 0.9a9 edition and we havnt finished the wireless patch > for > 1.1 yet. It should be done within the next days. > > A: Suse 10.0 & Bro 1.1 > B: Suse 10.0 & "Bro-wireless" 0.9a9 > VMware: Suse 10.0 Bro 1.1 so you have three Bro nodes? My guess is that the 0.9 one is causing the problem you're seeing. > The config.h are equal on both machines. Mhmmm are you sure about this? My guess is that on the 0.9 setup you need to add --enable-selectloop to the configure invocation. This ensures that events arriving from a remote Bro are treated with the same priority as observed packets. You can check whether that is the case by verifying that USE_SELECT_LOOP is defined in config.h after running configure. If the two config.h files really are identical, I don't know what the problem might be... Let us know how it goes. Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From christian at whoop.org Sun Oct 8 23:45:56 2006 From: christian at whoop.org (Christian Kreibich) Date: Sun, 08 Oct 2006 23:45:56 -0700 Subject: [Bro] [Fwd: Re: remote.bro] Message-ID: <1160376356.19379.13.camel@strangepork> FYI, an update from Sandro. -------- Forwarded Message -------- From: Sandro Reichert To: Christian Kreibich Subject: Re: [Bro] remote.bro Date: Sun, 08 Oct 2006 15:42:11 +0200 Hi! >> Im using Suse 10.0 on both machines. One Bro1.1 runs on PC 'A', the >> other on PC 'B' runs on VMware Server, because I started testing with >> our wireless 0.9a9 edition and we havnt finished the wireless patch >> for >> 1.1 yet. It should be done within the next days. >> >> A: Suse 10.0 & Bro 1.1 >> B: Suse 10.0 & "Bro-wireless" 0.9a9 >> VMware: Suse 10.0 Bro 1.1 > > so you have three Bro nodes? My guess is that the 0.9 one is causing the > problem you're seeing. The 0.9 is not included in the inter-bro communication, because it uses protocol version 4 and the 1.1 has version 5. I use 0.9 only for testing new (local) wireless events and the two 1.1 for testing communication. >> The config.h are equal on both machines. > > Mhmmm are you sure about this? My guess is that on the 0.9 setup you > need to add --enable-selectloop to the configure invocation. This > ensures that events arriving from a remote Bro are treated with the same > priority as observed packets. You can check whether that is the case by > verifying that USE_SELECT_LOOP is defined in config.h after running > configure. > > If the two config.h files really are identical, I don't know what the > problem might be... I made a diff and both 1.1 config.h were identical. Maybe, the problems are caused by VMware? As soon as our wireless-patch for 1.1 is finished, I'll install 1.1 on machine B without using VMware and tell u whether communication works better or not ;-) Bye, Sandro From christian at whoop.org Sun Oct 8 23:54:57 2006 From: christian at whoop.org (Christian Kreibich) Date: Sun, 08 Oct 2006 23:54:57 -0700 Subject: [Bro] [Fwd: Re: remote.bro] In-Reply-To: <1160376356.19379.13.camel@strangepork> References: <1160376356.19379.13.camel@strangepork> Message-ID: <1160376897.19379.22.camel@strangepork> Hi again Sandro, thanks for the feedback. On Sun, 2006-10-08 at 23:45 -0700, Christian Kreibich wrote: > > I made a diff and both 1.1 config.h were identical. > Maybe, the problems are caused by VMware? As soon as our wireless-patch > for 1.1 is finished, I'll install 1.1 on machine B without using VMware > and tell u whether communication works better or not ;-) So one thing I can think of that you could try is running broping, Broccoli's communication test tool: http://www.cl.cam.ac.uk/~cpk25/broccoli/manual/c85.html#AEN701 Basically you configure a Bro node to run a broping policy and then this node will return "pong" events for every "ping" event the ping client sends to the node. If the Bro node uses the select loop, this should definitely work without any live traffic at all. It also takes one Bro out of the equation, hopefully making it easier to pinpoint the Bro node causing the problem. Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From abhinay at cs.utexas.edu Thu Oct 12 17:08:07 2006 From: abhinay at cs.utexas.edu (Abhinay Kampasi) Date: Thu, 12 Oct 2006 19:08:07 -0500 Subject: [Bro] Defining a table inside a record Message-ID: <452ED8E7.5090101@cs.utexas.edu> Hi, In the bro scripting language (policy file), is it possible to define a table inside a record? I am trying to do so now and it results in a run-time error when I try to add an element to the table in the record for the first time. Thanks and Regards, Abhinay From vern at icir.org Thu Oct 12 19:26:36 2006 From: vern at icir.org (Vern Paxson) Date: Thu, 12 Oct 2006 19:26:36 -0700 Subject: [Bro] Defining a table inside a record In-Reply-To: <452ED8E7.5090101@cs.utexas.edu> (Thu, 12 Oct 2006 19:08:07 CDT). Message-ID: <200610130226.k9D2QaFP095080@jaguar.icir.org> Could you post a simple script demonstrating the problem? I believe I know what you're running up against, but it'll be easiest to show how to fix it given an example. Vern From abhinay at cs.utexas.edu Thu Oct 12 22:46:42 2006 From: abhinay at cs.utexas.edu (Abhinay Kampasi) Date: Fri, 13 Oct 2006 00:46:42 -0500 Subject: [Bro] Defining a table inside a record In-Reply-To: <200610130226.k9D2QaFP095080@jaguar.icir.org> Message-ID: Hi Vern, I have attached an example script. I get the following error when I run it: "1145312860.146852 ../policy/example.bro, line 16 (curr_info$temp_table): internal error: field value missing" Am I doing something wrong? Also, the ref-manual mentions that we should use "* expr" for doing a deep copy. I get an error when I try to do so. What is the correct syntax for doing a deep copy. Thanks and Regards, Abhinay -----Original Message----- From: bro-bounces at ICSI.Berkeley.EDU [mailto:bro-bounces at ICSI.Berkeley.EDU]On Behalf Of Vern Paxson Sent: Thursday, October 12, 2006 9:27 PM To: Abhinay Kampasi Cc: bro at bro-ids.org Subject: Re: [Bro] Defining a table inside a record Could you post a simple script demonstrating the problem? I believe I know what you're running up against, but it'll be easiest to show how to fix it given an example. Vern _______________________________________________ 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: example.bro Type: application/octet-stream Size: 440 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20061013/11a7fe76/attachment.obj From vern at icir.org Thu Oct 12 22:54:53 2006 From: vern at icir.org (Vern Paxson) Date: Thu, 12 Oct 2006 22:54:53 -0700 Subject: [Bro] Defining a table inside a record In-Reply-To: (Fri, 13 Oct 2006 00:46:42 CDT). Message-ID: <200610130554.k9D5sref098861@jaguar.icir.org> > Am I doing something wrong? It's subtle, but the problem is that this: local curr_info: temp_info; assigns a record value to curr_info but one that *doesn't have any of the fields initialized*. It's the same as if you had a field "foo: double" in the record - you couldn't then access temp_info$foo in an expression because it hasn't yet been assigned. The following will fix the problem. Change: ... local curr_info: temp_info; curr_info$temp_table[1] = "abhinay"; ... to ... local curr_info: temp_info; local table_val_for_record : table[count] of string; curr_info$temp_table = table_val_for_record; curr_info$temp_table[1] = "abhinay"; ... > Also, the ref-manual mentions that we should use "* expr" for doing a deep > copy. I get an error when I try to do so. What is the correct syntax for > doing a deep copy. Argh, that's out-of-date (where in the manual do you see it?). Instead use "copy(expr)". Vern From abhinay at cs.utexas.edu Thu Oct 12 23:26:49 2006 From: abhinay at cs.utexas.edu (Abhinay Kampasi) Date: Fri, 13 Oct 2006 01:26:49 -0500 Subject: [Bro] Defining a table inside a record In-Reply-To: <200610130554.k9D5sref098861@jaguar.icir.org> Message-ID: Thanks Vern, That fixed the problem. About deep copy, I am using version 0.9. If I use copy, Bro complains saying "unknown identifier copy". Is there any other way to do a deep copy in v0.9. Thanks, Abhinay -----Original Message----- From: bro-bounces at ICSI.Berkeley.EDU [mailto:bro-bounces at ICSI.Berkeley.EDU]On Behalf Of Vern Paxson Sent: Friday, October 13, 2006 12:55 AM To: Abhinay Kampasi Cc: bro at bro-ids.org Subject: Re: [Bro] Defining a table inside a record > Am I doing something wrong? It's subtle, but the problem is that this: local curr_info: temp_info; assigns a record value to curr_info but one that *doesn't have any of the fields initialized*. It's the same as if you had a field "foo: double" in the record - you couldn't then access temp_info$foo in an expression because it hasn't yet been assigned. The following will fix the problem. Change: ... local curr_info: temp_info; curr_info$temp_table[1] = "abhinay"; ... to ... local curr_info: temp_info; local table_val_for_record : table[count] of string; curr_info$temp_table = table_val_for_record; curr_info$temp_table[1] = "abhinay"; ... > Also, the ref-manual mentions that we should use "* expr" for doing a deep > copy. I get an error when I try to do so. What is the correct syntax for > doing a deep copy. Argh, that's out-of-date (where in the manual do you see it?). Instead use "copy(expr)". Vern _______________________________________________ Bro mailing list bro at bro-ids.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From vern at icir.org Thu Oct 12 23:30:23 2006 From: vern at icir.org (Vern Paxson) Date: Thu, 12 Oct 2006 23:30:23 -0700 Subject: [Bro] Defining a table inside a record In-Reply-To: (Fri, 13 Oct 2006 01:26:49 CDT). Message-ID: <200610130630.k9D6UN9Q099733@jaguar.icir.org> > About deep copy, I am using version 0.9. If I use copy, Bro complains saying > "unknown identifier copy". Is there any other way to do a deep copy in v0.9. No, it's a feature that was added in 1.0. Vern From christian at whoop.org Fri Oct 13 09:58:55 2006 From: christian at whoop.org (Christian Kreibich) Date: Fri, 13 Oct 2006 09:58:55 -0700 Subject: [Bro] Defining a table inside a record In-Reply-To: <200610130630.k9D6UN9Q099733@jaguar.icir.org> References: <200610130630.k9D6UN9Q099733@jaguar.icir.org> Message-ID: <1160758735.13449.44.camel@strangepork> On Thu, 2006-10-12 at 23:30 -0700, Vern Paxson wrote: > > About deep copy, I am using version 0.9. If I use copy, Bro complains saying > > "unknown identifier copy". Is there any other way to do a deep copy in v0.9. > > No, it's a feature that was added in 1.0. Well one can still do the deep copy manually, no? You'll need to go over your original data structure and assign all elementary fields to the new structure manually. Upgrading to 1.0+ is encouraged! I'll look into correcting the documentation regarding copy(). Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From sanreich at gmx.de Sun Oct 15 10:53:00 2006 From: sanreich at gmx.de (Sandro Reichert) Date: Sun, 15 Oct 2006 19:53:00 +0200 Subject: [Bro] RemoteSerializer.cc Message-ID: <4532757C.3010406@gmx.de> Hi! I'm still analyzing the inter-bro(1.1) communication :-) RemoteSerializer.cc line 634/635 and 637/638 are identical: if(our_class) p->our_class = our_class ; SocketComm::Run (): lines 2333 to 2361 [1] if ( io->IsFillingUp() && ! shutting_conns_down ) {} and [2] if ( ! io->IsFillingUp() && shutting_conns_down ) {} example: - bro node A is connected to nodes B and C. - B sent 4GB, C only 20MB - now C generates much traffic and A's queue to parent is filling up -> [1] becomes true, but instead of C, B is detected as the connection with the heaviest traffic and therefor disconnected; shutting_conns_down = true. - C still floods A, [1] and [2] are false and C can't be stopped. (?) My solution: [a] 'bytes_read' should be a dynamic value. I think this consumes more resources than [b], but will detect the heaviest connection [b] a timeout to set 'shutting_conns_down = false' if 'io->IsFillingUp()' is still true. Problem: in worst case, it will disconnect all notes and the heaviest connection is the last one. Bye Sandro From christian at whoop.org Mon Oct 16 13:55:30 2006 From: christian at whoop.org (Christian Kreibich) Date: Mon, 16 Oct 2006 13:55:30 -0700 Subject: [Bro] RemoteSerializer.cc In-Reply-To: <4532757C.3010406@gmx.de> References: <4532757C.3010406@gmx.de> Message-ID: <1161032130.21944.77.camel@strangepork> Hi, afaik this is just a band aid until we've implemented an app-layer flow control scheme -- killing a connection is suboptimal in any case. Is the issue you're describing a problem you're seeing in practice? On Sun, 2006-10-15 at 19:53 +0200, Sandro Reichert wrote: > SocketComm::Run (): lines 2333 to 2361 > [1] if ( io->IsFillingUp() && ! shutting_conns_down ) {} > and [2] if ( ! io->IsFillingUp() && shutting_conns_down ) {} > > example: > - bro node A is connected to nodes B and C. > - B sent 4GB, C only 20MB > - now C generates much traffic and A's queue to parent is filling up > -> [1] becomes true, but instead of C, B is detected as the > connection with the heaviest traffic and therefor disconnected; > shutting_conns_down = true. > - C still floods A, [1] and [2] are false and C can't be stopped. (?) [...] Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From robin at icir.org Mon Oct 16 16:19:02 2006 From: robin at icir.org (Robin Sommer) Date: Mon, 16 Oct 2006 16:19:02 -0700 Subject: [Bro] RemoteSerializer.cc In-Reply-To: <4532757C.3010406@gmx.de> References: <4532757C.3010406@gmx.de> Message-ID: <20061016231901.GA5878@icir.org> On Sun, Oct 15, 2006 at 19:53 +0200, you wrote: > I'm still analyzing the inter-bro(1.1) communication :-) Seems you're doing a thorough code review. :-) > RemoteSerializer.cc > line 634/635 and 637/638 are identical: > if(our_class) > p->our_class = our_class ; That's pretty certainly a left-over from merging in a patch at some point. I'll get rid of the duplicate. > - C still floods A, [1] and [2] are false and C can't be stopped. (?) Yes, you're right. Like Christian, I'd be interested to know whether you've run into this problem in practice. As Christian also mentioned, shutting connections down is only kind of an emergency break, lacking something more sophisticated at the moment. However, one of your solutions (I'm tending towards [b]) might be worth implementing if this turns out to be problematic. Thanks for pointing these things out! Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org LBNL/ICSI * Fax +1 (510) 666-2956 * www.icir.org From sanreich at gmx.de Tue Oct 17 07:35:38 2006 From: sanreich at gmx.de (Sandro Reichert) Date: Tue, 17 Oct 2006 16:35:38 +0200 Subject: [Bro] RemoteSerializer.cc In-Reply-To: <20061016231901.GA5878@icir.org> References: <4532757C.3010406@gmx.de> <20061016231901.GA5878@icir.org> Message-ID: <4534EA3A.4080103@gmx.de> Hi! > Seems you're doing a thorough code review. :-) more or less, i'm writing a short (german) documentation how inter-bro communication can be used for mobile WLAN clients - so I have to understand how it works. >> - C still floods A, [1] and [2] are false and C can't be stopped. (?) > > Yes, you're right. Like Christian, I'd be interested to know whether > you've run into this problem in practice. No, it was just an idea while reading the code. > As Christian also mentioned, shutting connections down is only kind > of an emergency break, lacking something more sophisticated at the > moment. However, one of your solutions (I'm tending towards [b]) > might be worth implementing if this turns out to be problematic. > > Thanks for pointing these things out! :-) What is done in the state synchronization? I tried to figure it out, but it was too complex. Thanks! Sandro From christian at whoop.org Tue Oct 17 09:54:12 2006 From: christian at whoop.org (Christian Kreibich) Date: Tue, 17 Oct 2006 09:54:12 -0700 Subject: [Bro] RemoteSerializer.cc In-Reply-To: <4534EA3A.4080103@gmx.de> References: <4532757C.3010406@gmx.de> <20061016231901.GA5878@icir.org> <4534EA3A.4080103@gmx.de> Message-ID: <1161104052.21944.167.camel@strangepork> On Tue, 2006-10-17 at 16:35 +0200, Sandro Reichert wrote: > Hi! > > > > Seems you're doing a thorough code review. :-) > > more or less, i'm writing a short (german) documentation how inter-bro > communication can be used for mobile WLAN clients - so I have to > understand how it works. Could you, uhm, write it in English and not focus too much on mobility? We could use some docuware on the subject. ;) Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From robin at icir.org Tue Oct 17 10:17:51 2006 From: robin at icir.org (Robin Sommer) Date: Tue, 17 Oct 2006 10:17:51 -0700 Subject: [Bro] RemoteSerializer.cc In-Reply-To: <4534EA3A.4080103@gmx.de> References: <4532757C.3010406@gmx.de> <20061016231901.GA5878@icir.org> <4534EA3A.4080103@gmx.de> Message-ID: <20061017171751.GC7178@icir.org> On Tue, Oct 17, 2006 at 16:35 +0200, Sandro Reichert wrote: > more or less, i'm writing a short (german) documentation how inter-bro > communication can be used for mobile WLAN clients Cool! Can you send me a copy when you're done? (Or even before if you'd like to get feedback.) > What is done in the state synchronization? It works. :-) Just setup the connections between peers as you do for event-passing and then declare some script variables (e.g., tables) to be &synchronized. All operations performed on these variables will then be propagated across the peers, and all of them will share the same view of the synchronized state. Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org LBNL/ICSI * Fax +1 (510) 666-2956 * www.icir.org From frenzy at frenzy.org Tue Oct 17 10:41:41 2006 From: frenzy at frenzy.org (frenzy at frenzy.org) Date: Tue, 17 Oct 2006 11:41:41 -0600 (MDT) Subject: [Bro] Case insensitive pattern matching Message-ID: How does one do insensitive pattern matching in Bro? ie similar to /test/i I saw this topic come up on the forum earlier, but I didn't notice a response to that part of the question. Is there a way to do it that doesn't use [tT][eE][sS][tT] format? :) Thank you, Randy http://www.frenzy.org "Sed Quis Custodiet Ipsos Custodes?" -Juvenal From vern at icir.org Tue Oct 17 10:52:44 2006 From: vern at icir.org (Vern Paxson) Date: Tue, 17 Oct 2006 10:52:44 -0700 Subject: [Bro] Case insensitive pattern matching In-Reply-To: (Tue, 17 Oct 2006 11:41:41 MDT). Message-ID: <200610171752.k9HHqiQd065366@jaguar.icir.org> > Is there a way to do it that doesn't use [tT][eE][sS][tT] format? :) Unfortunately, no. I agree that this is lame and have been meaning to add an &insensitive attribute that marks a regular-expression as case-insensitive but um no luck finding time for it so far. Vern From robin at icir.org Tue Oct 17 11:21:06 2006 From: robin at icir.org (Robin Sommer) Date: Tue, 17 Oct 2006 11:21:06 -0700 Subject: [Bro] Case insensitive pattern matching In-Reply-To: References: Message-ID: <20061017182106.GB7878@icir.org> On Tue, Oct 17, 2006 at 11:41 -0600, frenzy at frenzy.org wrote: > Is there a way to do it that doesn't use [tT][eE][sS][tT] format? :) No, unfortunately there isn't yet. Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org LBNL/ICSI * Fax +1 (510) 666-2956 * www.icir.org From vern at icir.org Tue Oct 17 19:06:49 2006 From: vern at icir.org (Vern Paxson) Date: Tue, 17 Oct 2006 19:06:49 -0700 Subject: [Bro] new Bro CURRENT and STABLE releases (1.2 and 1.1) Message-ID: <200610180206.k9I26nUO073703@jaguar.icir.org> Bro release 1.2 is now available from: ftp://bro-ids.org/bro-1.x-current.tar.gz This becomes the new CURRENT release. The 1.1 branch (formerly CURRENT) is now the STABLE release: ftp://bro-ids.org/bro-1.1-stable.tar.gz The most significant new features with 1.2 are dynamic protocol detection and a large set of enhancements to the BinPAC system for generating protocol analyzers. The appended changelog lists numerous other features/changes/fixes. The old STABLE release, based on the 0.9 release, remains available at ftp://bro-ids.org/bro-pub-0.9-stable.tar.gz We do not anticipate making any further changes to it. Vern -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1.2 Tue Oct 17 12:09:49 PDT 2006 - Bro now supports DPD, dynamic protocol detection (Robin Sommer, Holger Dreger, and Michael Mai). With DPD, Bro can analyze protocols regardless of what port numbers they use: it infers the protocol based on which application analyzers can parse it without error. Adding this functionality involved extensive changes to Bro's internals, but also now enables multiple Bro analyzers to work on the same connection, either concurrently or one nested inside the other (we have not taken much advantage of this latter capability yet, but see the FTP events discussed below). There are a number of new policy scripts, events, and variables associated with DPD processing, as follows. Scripts: You activate DPD by @load'ing dpd.bro. It in turn instructs Bro to load the signature file policy/sigs/dpd.sig. Note that Bro uses signatures to expedite deciding which analyzers to try on a given connection; it does *not* simply use the signatures to make the determination of which protocol is in use, as this is insufficiently robust. (At this point, Bro provides signatures for FTP, IRC, HTTP, SMTP, and SSH. In the future we plan to add other protocols.) Along with dpd.bro, you need to @load detect-protocols.bro or detect-protocols-http.bro. The former enables general detection of application-layer protocols, while the latter does further inspection of HTTP sessions to characterize applications running on top of HTTP such as Gnutella or SOAP. (Loading dpd.bro is separate from loading one of these scripts because in principle Bro could use a different means than signatures to activate the analyzers, although currently it does not.) If you @load dyn-disable.bro, then once an analyzer determines that it does not match a given connection, it is deactivated (and a Notice is generated). Otherwise, it still proceeds to try its best to analyze the connection (to possibly be more robust against evasion). The scripts dce.bro and smb.bro enable DPD for the Windows DCE and SMB protocols, respectively. (Note that analysis of these protocols is undergoing a major expansion, not yet complete.) Events: event protocol_confirmation(c: connection, atype: count, aid: count) Generated when the given connection has been confirmed as conforming with the application type (protocol) specified by atype. aid is a globally unique analyzer ID that identifies a particular analyzer instance. The values for atype are symbolic names associated with each of Bro's analyzers, such as ANALYZER_IRC. See the initialization at the beginning of Analyzer.cc for the full set of names. The function analyzer_name(atype: count): string translates these symbolic names into text. For example, analyzer_name(ANALYZER_IRC) yields "IRC". event protocol_violation(c: connection, atype: count, aid: count, reason: string) Generated when the given connection has been found to violate the protocol of the given application type, with "reason" giving details. Variables: dpd_buffer_size: count (default 1024) Specifies how much pending data Bro keeps for connections that have not been classified yet. Once this fills, the data is deleted, though classification can still continue (see below). dpd_match_only_beginning: bool (default T) If set, specifies that Bro should stop signature matching if it has processed dpd_buffer_size bytes. dpd_ignore_ports: bool (default F) If set, then Bro does not take into consideration the port numbers associated with connections when attempting to classify them (which can otherwise help the process in some cases). dpd_reassemble_first_packets: bool (default T) If set, then Bro does TCP stream reassembly before applying signature-matching to detect protocols. likely_server_ports: set[port] Specifies a list of ports that Bro will consider as likely used by servers. For example, if Bro sees a connection that has already been established (so it does not know which side sent the initial SYN), and one side uses a port in this set, then it will assume that that side is the server (connection responder). The set is empty unless you populate it or @load server-ports.bro, which specifies a large number of values. dpd_config: table[AnalyzerTag] of dpd_protocol_config Specifies the DPD configuration associated with each tag. The type dpd_protocol_config is simply: type dpd_protocol_config: record { ports: set[port] &optional; }; i.e., an optional $ports field specifying a set of ports associatd with the tag. For example, ftp.bro now includes the equivalent of: redef dpd_config += { [ANALYZER_FTP] = [$ports = 21/tcp] }; Functions: The function expect_connection(orig: addr, resp: addr, resp_p: port, analyzer: count, tout: interval) is called to alert Bro that a new connection is expected, initiated by orig to a server running on resp's port resp_p (note: orig's port is not specified) which will correspond to the specified analyzer (e.g., "FILE", which is used to analyze files transferred by FTP - see next item). "tout" is a timeout to associate with the waiting. The function function disable_analyzer(cid: conn_id, aid: count) instructs Bro to disable the analyzer that generated the current event, assuming the analyzer is associated with the given connection ID. This is used by the dyn-disable.bro script discussed above. - A much more complete BinPAC compiler, along with new HTTP, DNS, and RPC/Portmap analyzers in binpac (Ruoming Pang). The flag "--use-binpac" activates the BinPAC-based analyzers (currently for HTTP and DNS). See www.cs.princeton.edu/~rpang/binpac-paper.pdf for a description of BinPAC, and let Ruoming know if you are interested in using BinPAC to build new analyzers. - A new type of analyzer, FILE, analyzes the contents of a connection as though it were a data file (Robin Sommer). Currently, it can generate two events: event file_transferred(c: connection, prefix: string, descr: string, mime_type: string) Indicates that the connection transferred a file. "prefix" is the beginning of the file's data; "descr" and "mime_type" are indicators of the file's type, as reported by the "libmagic" library. descr/mime_type are only set if Bro is configured on a system that includes the "libmagic" library. event file_virus(c: connection, virname: string) Indicates the connection transferred an executable corresponding to a known virus of the given name. This functionality is only available if Bro is configured on a system that includes the "libclamav" library. Note, this analyzer is enabled via a call to expect_connection by the FTP analyzer. - New events relating to IRC analysis (Robin Sommer): event irc_client(c: connection, prefix: string, data: string) Generated upon seing a client message sent over the given IRC connection. "prefix" is the command's prefix as defined by the IRC protocol. It is used by servers to indicate the true origin of the message; it may be empty. "data" contains the message. event irc_server(c: connection, prefix: string, data: string) Same for server messages. event irc_user_message(c: connection, user: string, host: string, server: string, real_name: string) Generated upon seeing an IRC "USER" command. event irc_password_message(c: connection, password: string) Generated upon seeing an IRC "PASS" command. event irc_channel_topic(c: connection, channel: string, topic: string) Generated upon seeing an IRC server reply that includes the channel topic. event irc_global_users(c: connection, prefix: string, msg: string) Generated upon seeing an IRC server reply that includes a count of the number of IRC users. - The new experimental script irc-bot.bro tracks IRC-based bots (Robin Sommer). The accompanying script irc-bot-syslog.bro syslog's the state of the bot analysis every IrcBot::summary_interval seconds (default 1 minute). - The new script proxy.bro looks for open Web proxies by matching incoming requests to a server with outgoing requests it makes (Robin Sommer). It generates HTTPProxyFound Notices when it finds one. - Changes to notices.bro (Robin Sommer): - notice_policy_item's now have a default $result of NOTICE_FILE and a default $priority of 1. - The new notice_action_filter, notice_alarm_per_orig, alarms on the first NoticeType from a specific source. Subsequent instances are tallied. - notice_action_filters now reside in the new script notice-action-filter.bro (automatically loaded by notice.bro). - The notice actions NOTICE_ALARM_PER_CONN, NOTICE_ALARM_PER_ORIG, and NOTICE_ALARM_ONCE have been removed, as they were never actually implemented. - If the notice_policy returns IGNORE or FILE, the action_filters filters are no longer consulted. - A new attribute for tables and sets, &mergeable, changes the semantics of assignments, as follows (Robin Sommer). Given two &mergeable tables/sets A and B, an assignment "A = B" becomes actually a join "A = A \cup B" (i.e., union). The envisoned use is to help avoid race conditions when doing remote state synchronization. - The semantics of &synchronized expire_funcs has changed (Robin Sommer). Now, when a table entry is expired and the operation is propagated to a a peer, the peer will call its expire_function. - TRW analysis now skips UDP traffic because it currently treats all UDP connections as failures (Robin Sommer). - trw.bro has been split into trw-impl.bro (the algorithm) and trw.bro (which simply activates the analysis), to facilitate writing scripts that have hooks into TRW analysis but don't presume it's active (Robin Sommer). - The option report_remote_notices in remote.bro has been replaced by a new script you include, remote-report-notices.bro (Robin Sommer). - The new function connect_peer() explicitly connects to a remote host (Robin Sommer). - The new script remote-send-id.bro sends the current value of an ID to a remote Bro and then terminates processing (Robin Sommer). It's intended for use from the command-line, as in bro -e "redef dst="" id="" remote-send-id The other scripts must set up the connection. is an index into Remote::destinations corresponding to the destination. - New built-ins {suspend,resume}_state_updates() can be called to temporarily avoid propagating updates to &sync'ed values (Robin Sommer). This can avoid duplicated activity. - The new function terminate_communication() instructs Bro to end its communication with remote peers (Robin Sommer). - The new event remote_state_access_performed is raised when remote state access has been performed (Robin Sommer). This is primarily for debugging. - The log() built-in has been renamed to ln() to avoid conflict (Vern Paxson). - bifcl now generates event generation wrapper functions from event.bif (Ruoming Pang). For example, to generate event http_reply, currently one writes: val_list* vl = new val_list; vl->append(BuildConnVal()); vl->append(new StringVal(fmt("%.1f", reply_version))); vl->append(new Val(reply_code, TYPE_COUNT)); if ( reply_reason_phrase ) vl->append(reply_reason_phrase); else vl->append(new StringVal("")); ConnectionEvent(http_reply, vl); In the future, one will be able to just call bro_event_http_reply(), and the code generated by bifcl looks like: void bro_event_http_reply(Connection* c, StringVal* version, bro_uint_t code, StringVal* reason) { val_list* vl = new val_list; vl->append(c->BuildConnVal()); vl->append(version); vl->append(new Val(code, TYPE_COUNT)); vl->append(reason); mgr.QueueEvent(http_reply, vl, SOURCE_LOCAL, c); } Accompanying this change is a semantic shift to types "string" and "port" in .bif files. They used to be translated to C++ types BroString* and uint32, respectively. Now they are translated to StringVal* and PortVal*. The functions in bro.bif are changed accordingly, and please be aware of this change when you write built-in functions in future. Also for this change, the parameter 'new' for rsh_request has been renamed 'new_session', as 'new' is a reserved word for C++. - Some ICMP "connections" now have services identified ("icmp-echo", "icmp-unreach") rather than just listing the service as "other" (Ruoming Pang). - The new option remote_trace_sync_interval specifies an interval after which each Bro will stop processing its trace and wait for all others to signal that they have reached the same time (Robin Sommer). The intent is support for operating Bro in a distributed cluster fashion (and in particular for debugging such clusters when running off-line on traces). This option only works in pseudo-realtime mode, and requires the new global remote_trace_sync_peers to give the total number of remote peers (not including self). Signaling is done via a new communication message type. - Extensions for DNS transformation/anonymization, including introduction of trace transformation for protocols other than TCP (Jason Lee). Not yet fully developed/debugged. - Extensions for HTTP transformation/anonymization (Martin Casado). Not yet fully developed/debugged. - The $conn field is now included in HTTPProxyFound notices (Robin Sommer). - Changed service inference algorithm to favor lower-numbered likely-servers over higher-numbered ones (Vern Paxson). - In pseudo-realtime mode, Bro now uses real-time for deciding which peer should send state (Robin Sommer). - Time synchronization for Bro's running on traces in pseudo-realtime mode added (Robin Sommer). - Avoidance of false content gaps improved when sorting packets with out-of-order timestamps (Ruoming Pang). - Packets from the packet sorter are now more robustly drained upon termination of input (Ruoming Pang). - Documentation for deep-copy updated (Christian Kreibich). - Nasty fragment reassembly bug fixed (Vern Paxson). - Serious bugs in EDNS0 processing fixed (Vern Paxson). - Fixed significant misfeature of interconn.bro that stopped all processing of a connection once it makes a detection (Vern Paxson). - Fixes for &read_expire operation across synchronizes tables (Robin Sommer). - Fixes for multiple peers exchanging initial &sync state simultaneously (Robin Sommer). - Improvements to graceful termination of Bro when communicating with remote peers (Robin Sommer). - Fix for ICMP analyzer not always generating icmp_sent events (Robin Sommer). This appears to still need some work, as now it generates redundant events. - Fix for initial exchange of &sync state which could lead to referencing unknown IDs (Robin Sommer). - Fix to scan detection for differing semantics of connection compressor vs. non-compressor (Robin Sommer). - Bug fix for distinguishing regular expression matches of length 0 from those of length 1 (Ruoming Pang). - Fix for SSH version parsing in the presence of content gaps (Robin Sommer). - Bug fix for IRC that could lead to crashes (Robin Sommer). - Bug fix to refrain from adding new timers when a connection has already been removed from the connection table (Robin Sommer). - Bug fix for packet_contents not including the transport-layer header (Robin Sommer). - Some memory leaks fixed (Robin Sommer). - A bunch of portability and distribution problems fixed (Christian Kreibich, Robin Sommer, Vern Paxson). From seth at net.ohio-state.edu Wed Oct 18 08:02:23 2006 From: seth at net.ohio-state.edu (Seth Hall) Date: Wed, 18 Oct 2006 11:02:23 -0400 Subject: [Bro] new Bro CURRENT and STABLE releases (1.2 and 1.1) In-Reply-To: <200610180206.k9I26nUO073703@jaguar.icir.org> References: <200610180206.k9I26nUO073703@jaguar.icir.org> Message-ID: <545E4CD3-C1FF-47A7-9A07-FC82B8A45856@net.ohio-state.edu> On Oct 17, 2006, at 10:06 PM, Vern Paxson wrote: > Bro release 1.2 is now available from: Awesome! I'm really looking forward to working with the new functionality in 1.2. > - A much more complete BinPAC compiler, along with new HTTP, DNS, and > RPC/Portmap analyzers in binpac (Ruoming Pang). The flag "--use- > binpac" > activates the BinPAC-based analyzers (currently for HTTP and DNS). > See www.cs.princeton.edu/~rpang/binpac-paper.pdf for a > description of > BinPAC, and let Ruoming know if you are interested in using > BinPAC to build > new analyzers. The --use-binpac flag doesn't work in the downloadable package. Are the binpac analyzers being used by default? Thanks, .Seth From vern at icir.org Wed Oct 18 08:11:59 2006 From: vern at icir.org (Vern Paxson) Date: Wed, 18 Oct 2006 08:11:59 -0700 Subject: [Bro] --use-binpac (Re: new Bro CURRENT and STABLE releases (1.2 and 1.1) ) In-Reply-To: <545E4CD3-C1FF-47A7-9A07-FC82B8A45856@net.ohio-state.edu> (Wed, 18 Oct 2006 11:02:23 EDT). Message-ID: <200610181511.k9IFBx8E022019@jaguar.icir.org> > The --use-binpac flag doesn't work in the downloadable package. What happens when you try using it? It works for me. Vern From seth at net.ohio-state.edu Wed Oct 18 08:25:56 2006 From: seth at net.ohio-state.edu (Seth Hall) Date: Wed, 18 Oct 2006 11:25:56 -0400 Subject: [Bro] --use-binpac (Re: new Bro CURRENT and STABLE releases (1.2 and 1.1) ) In-Reply-To: <200610181511.k9IFBx8E022019@jaguar.icir.org> References: <200610181511.k9IFBx8E022019@jaguar.icir.org> Message-ID: On Oct 18, 2006, at 11:11 AM, Vern Paxson wrote: >> The --use-binpac flag doesn't work in the downloadable package. > > What happens when you try using it? It works for me. Sigh... I should try looking around a little longer in the future. I thought that --use-binpac was a configure option, but I see now that it's an option for the bro binary. Thanks for the quick response. .Seth From geek00l at gmail.com Wed Oct 18 16:36:04 2006 From: geek00l at gmail.com (CS Lee) Date: Thu, 19 Oct 2006 07:36:04 +0800 Subject: [Bro] Enable clamav Message-ID: <1bb5dd90610181636u414379f0na41629ff661f0d74@mail.gmail.com> Gentle people, Congrats for the new milestone again. While I notice that I can have bro running with clamav in 1.2, I try to search for the configure option and apparently there's none. I'm on FreeBSD and have clamav install via package thus the clamav.h resides in /usr/local/includes/, is there a way or I have overlooked into it. Thanks. -- Best Regards, CS Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20061019/daf1b379/attachment.html From robin at icir.org Wed Oct 18 18:16:12 2006 From: robin at icir.org (Robin Sommer) Date: Wed, 18 Oct 2006 18:16:12 -0700 Subject: [Bro] Enable clamav In-Reply-To: <1bb5dd90610181636u414379f0na41629ff661f0d74@mail.gmail.com> References: <1bb5dd90610181636u414379f0na41629ff661f0d74@mail.gmail.com> Message-ID: <20061019011612.GF24555@icir.org> On Thu, Oct 19, 2006 at 07:36 +0800, CS Lee wrote: > Congrats for the new milestone again. Thanks! > running with clamav in 1.2, I try to search for the configure option and There's is indeed no particular option (yet); configure just looks for libclamv in the default paths. If this doesn't work, try giving the necessary flags manually: CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org LBNL/ICSI * Fax +1 (510) 666-2956 * www.icir.org From geek00l at gmail.com Thu Oct 19 00:36:37 2006 From: geek00l at gmail.com (CS Lee) Date: Thu, 19 Oct 2006 15:36:37 +0800 Subject: [Bro] Bro-IDS Upgrade Message-ID: <1bb5dd90610190036t3f5c00a0nef2e7c653ef9a812@mail.gmail.com> Hey all, What's the best procedure to upgrade from bro-1.1 to bro-1.2, does the make update work anymore? Thanks. -- Best Regards, CS Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20061019/8e9f186d/attachment.html From bltierney at lbl.gov Thu Oct 19 08:18:52 2006 From: bltierney at lbl.gov (Brian Tierney) Date: Thu, 19 Oct 2006 08:18:52 -0700 Subject: [Bro] Bro-IDS Upgrade In-Reply-To: <1bb5dd90610190036t3f5c00a0nef2e7c653ef9a812@mail.gmail.com> References: <1bb5dd90610190036t3f5c00a0nef2e7c653ef9a812@mail.gmail.com> Message-ID: <4537975C.5070000@lbl.gov> If you did a 'make install-brolite' for 1.1, then just doing 'make install' should be all you need to do. Otherwise you need to be a bit careful to not clobber any of your local mods. CS Lee wrote: > Hey all, > > What's the best procedure to upgrade from bro-1.1 to bro-1.2, does the > make update work anymore? > > Thanks. > > -- > Best Regards, > > CS Lee > > > ------------------------------------------------------------------------ > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro -- ------------------------------------------------------------------------ Brian L. Tierney, Lawrence Berkeley National Laboratory (LBNL) 1 Cyclotron Rd. MS: 50B-2239, Berkeley, CA 94720 tel: 510-486-7381 fax: 510-495-2998 efax: 425-642-4558 bltierney at lbl.gov http://www-didc.lbl.gov/~tierney ------------------------------------------------------------------------ From geek00l at gmail.com Thu Oct 19 19:44:11 2006 From: geek00l at gmail.com (CS Lee) Date: Fri, 20 Oct 2006 10:44:11 +0800 Subject: [Bro] Bro-IDS v1.2 compile Message-ID: <1bb5dd90610191944t2682d705r14e26eb70a85aeea@mail.gmail.com> Gentle people, Just to confirm that make install bro-lite no longer necessary on version 1.2 if doing fresh install right. Thanks. -- Best Regards, CS Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20061020/2e8b2aa5/attachment.html From sanreich at gmx.de Fri Oct 20 04:32:11 2006 From: sanreich at gmx.de (Sandro Reichert) Date: Fri, 20 Oct 2006 13:32:11 +0200 Subject: [Bro] sending a question to a special peer Message-ID: <4538B3BB.6070909@gmx.de> Hi! Nodes: A -- B -- C The function send_ping (bro.bif) is used for sending a ping only to the given event_peer, not to all peers im connected with, right? That means, B can ping C, without sending the ping to A.(?) Is there a function to do this with events? Example: A has requested all events from B B has requested all events from A and C C has requested all events from B Now B wants to send a special question event to A, but not to C. I think there is no function yet? -> A and C are receiving this event. My solution is that the event 'question' has a destination-address and every peer receiving the event compares this address with its own. event question(dest: addr, [...]) { if( is_remote_event() && my_addr == dest) {do something, awnser} } @robin >> more or less, i'm writing a short (german) documentation how >> inter-bro communication can be used for mobile WLAN clients > Cool! Can you send me a copy when you're done? Sure!! > (Or even before if you'd like to get feedback.) Yes, Thanks!! :-)) Thanks, Sandro From Stephen.Smith at dodig.mil Fri Oct 20 04:52:05 2006 From: Stephen.Smith at dodig.mil (Smith, Stephen G., OIG DoD) Date: Fri, 20 Oct 2006 07:52:05 -0400 Subject: [Bro] More info on Bro workshop at SC'06 In-Reply-To: <20060927163026.GA26037@wolrab.ncsa.uiuc.edu> Message-ID: <6E3798E4162B36459A2ED20EC5F17236063CFA4C@01A017MH_A.dodig.mil> Any updates on the Bro workshop? Of particular interest is confirmation on what, if any, registration requirements need to be fulfilled. I'd like to make sure I don't get buried in paperwork at the last minute. Thanks, Stephen -----Original Message----- From: bro-bounces at ICSI.Berkeley.EDU [mailto:bro-bounces at ICSI.Berkeley.EDU] On Behalf Of James J. Barlow Sent: Wednesday, September 27, 2006 12:30 To: bro at bro-ids.org Subject: [Bro] More info on Bro workshop at SC'06 A few people have asked about whether or not you need to register for the SC'06 conference to attend the workshop. The workshop is not affiliated with the conference, so you do not need to register. However, depending on where the workshop room is located, there is a chance that people may need to purchase a guest pass to get to the room. I'd like to try and prevent this from happening, but we'll try to let people know if that is going to be the case as soon as we get more info. -- James J. Barlow Head of Security Operations and Incident Response National Center for Supercomputing Applications Voice : (217)244-6403 1205 West Clark Street, Urbana, IL 61801 Cell : (217)840-0601 http://www.ncsa.uiuc.edu/~jbarlow Fax : (217)244-1987 _______________________________________________ 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: smime.p7s Type: application/x-pkcs7-signature Size: 4684 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20061020/26c36f99/attachment.bin From bltierney at lbl.gov Fri Oct 20 12:47:46 2006 From: bltierney at lbl.gov (Brian Tierney) Date: Fri, 20 Oct 2006 12:47:46 -0700 Subject: [Bro] updated Bro STABLE release 1.1c In-Reply-To: <200610180206.k9I26nUO073703@jaguar.icir.org> References: <200610180206.k9I26nUO073703@jaguar.icir.org> Message-ID: <453927E2.7070300@lbl.gov> A couple important bug fixes from the 1.2 release have been backported to the 1.1 release. A new version is available as: ftp://bro-ids.org/bro-1.1-stable.tar.gz Here is a list of bug fixes: - Nasty fragment reassembly bug fixed (Vern Paxson). - Minor fix for IRC backdoor detector (Vern Paxson). - Fixed serious bugs in DNS EDNS0 processing (Vern Paxson). From robin at icir.org Fri Oct 20 16:12:08 2006 From: robin at icir.org (Robin Sommer) Date: Fri, 20 Oct 2006 16:12:08 -0700 Subject: [Bro] sending a question to a special peer In-Reply-To: <4538B3BB.6070909@gmx.de> References: <4538B3BB.6070909@gmx.de> Message-ID: <20061020231208.GB6142@icir.org> On Fri, Oct 20, 2006 at 13:32 +0200, you wrote: > Is there a function to do this with events? No, not yet. Bro's model for distribtuting events is currently very simple: there's only broadcast. We're are thinking about adding more sophisticated schemes (e.g, groups of hosts subscribing to events, unicast messages, message routing, etc.) but so far that's only in an early planing stage. Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org LBNL/ICSI * Fax +1 (510) 666-2956 * www.icir.org From jbarlow at ncsa.uiuc.edu Mon Oct 23 09:47:48 2006 From: jbarlow at ncsa.uiuc.edu (James J. Barlow) Date: Mon, 23 Oct 2006 11:47:48 -0500 Subject: [Bro] More info on Bro workshop at SC'06 In-Reply-To: <6E3798E4162B36459A2ED20EC5F17236063CFA4C@01A017MH_A.dodig.mil> Message-ID: <20061023164748.GA25526@wolrab.ncsa.uiuc.edu> On Fri, Oct 20, 2006 at 07:52:05AM -0400, Smith, Stephen G., OIG DoD wrote: > Any updates on the Bro workshop? Of particular interest is confirmation on > what, if any, registration requirements need to be fulfilled. I'd like to > make sure I don't get buried in paperwork at the last minute. You won't need to register for the conference, but may need a guest pass. I'm still trying to work out where the workshop will be held (space is at a premium because of the conference). I should have a web page with all the details on the workshop up in the next day or so. I'll post a message to the list once I do. > -----Original Message----- > From: bro-bounces at ICSI.Berkeley.EDU [mailto:bro-bounces at ICSI.Berkeley.EDU] > On Behalf Of James J. Barlow > Sent: Wednesday, September 27, 2006 12:30 > To: bro at bro-ids.org > Subject: [Bro] More info on Bro workshop at SC'06 > > A few people have asked about whether or not you need to register for the > SC'06 conference to attend the workshop. The workshop is not affiliated > with the conference, so you do not need to register. However, depending > on where the workshop room is located, there is a chance that people may > need to purchase a guest pass to get to the room. I'd like to try and > prevent this from happening, but we'll try to let people know if that > is going to be the case as soon as we get more info. > > > -- > James J. Barlow > Head of Security Operations and Incident Response > National Center for Supercomputing Applications Voice : (217)244-6403 > 1205 West Clark Street, Urbana, IL 61801 Cell : (217)840-0601 > http://www.ncsa.uiuc.edu/~jbarlow Fax : (217)244-1987 > _______________________________________________ > 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 -- James J. Barlow Head of Security Operations and Incident Response National Center for Supercomputing Applications Voice : (217)244-6403 1205 West Clark Street, Urbana, IL 61801 Cell : (217)840-0601 http://www.ncsa.uiuc.edu/~jbarlow Fax : (217)244-1987 From mcuttler at bnl.gov Tue Oct 24 19:24:51 2006 From: mcuttler at bnl.gov (Matt Cuttler) Date: Tue, 24 Oct 2006 22:24:51 -0400 Subject: [Bro] bridge interface vs. bpf bonding (patch?) on FreeBSD 6.1 Message-ID: <453ECAF3.5060807@bnl.gov> Ennobled bro users and developers, I'm looking for some clarification on the use of bro and multiple interfaces. FreeBSD 6.1 machine with two em* (Intel 1000 fibre) interfaces. Each interface's RX port is connected to one of the two TX ports on a regenerative tap. Bro.cfg was originally configured as: BRO_CAPTURE_INTERFACE="em0 em1" Additionally, we tried enabling and disabling: BRO_BPFBOND_ENABLE="YES" and BRO_BPFBOND_FLAGS="em0 em1" In all cases above, we got indications that this configuration was not correct, and that bro might not be getting all of the traffic across both interfaces properly (see example #1 below, with content gaps in the smtp log). We then set up a bond interface: ifconfig bridge0 create ifconfig bridge0 addm em0 addm em1 up ..and changed our bro.cfg to: BRO_CAPTURE_INTERFACE="bond0" BRO_BPFBOND_ENABLE="NO" This seems to work properly now; at least we no longer get content gaps logged to the smtp log (see example #2 below). My questions are: Is this (bridge device method) the "right" way to handle multiple interfaces for my hardware/software? The documentation mentions kernel patches to enable bpf bonding on FreeBSD 4.1. Is this not necessary on later FreeBSD releases? Thanks, Matt Cuttler === example #1, using em0 and em1: 1.2.3.4/1880 > 5.6.7.8/smtp start internal 1.2.3.4/1880 > 5.6.7.8/smtp: unexpected: content gap: \ seq = 30, len = 33 1.2.3.4/1880 < 5.6.7.8/smtp: unusual command/reply: \ (UNKNOWN)() --> 250(OK) 1.2.3.4/1880 > 5.6.7.8/smtp: unexpected: unexpected \ command: RCPT reply = 0 state = 12 1.2.3.4/1880 < 5.6.7.8/smtp: unexpected: content gap: \ seq = 139, len = 14 1.2.3.4/1880 < 5.6.7.8/smtp: unexpected: content gap: \ seq = 153, len = 14 1.2.3.4/1880 < 5.6.7.8/smtp: unusual command/reply: \ (UNKNOWN)() --> 250(Accepted) 1.2.3.4/1880 > 5.6.7.8/smtp: unexpected: unexpected \ command: DATA reply = 0 state = 12 1.2.3.4/1880 > 5.6.7.8/smtp: unexpected: content gap: \ seq = 149, len = 1460 1.2.3.4/1880 > 5.6.7.8/smtp: unexpected: content gap: \ seq = 1609, len = 1697 1.2.3.4/1880 < 5.6.7.8/smtp: unexpected: content gap: \ seq = 237, len = 28 1.2.3.4/1880 < 5.6.7.8/smtp: unusual command/reply: \ (UNKNOWN)() --> 221(mail.host.net closing connection) finish === === Example #2, using bond0: 1.2.3.4/19100 > 5.6.7.8/smtp start external recipient: finish === From jives at security.berkeley.edu Wed Oct 25 09:21:33 2006 From: jives at security.berkeley.edu (John Ives) Date: Wed, 25 Oct 2006 09:21:33 -0700 Subject: [Bro] bridge interface vs. bpf bonding (patch?) on FreeBSD 6.1 In-Reply-To: <453ECAF3.5060807@bnl.gov> References: <453ECAF3.5060807@bnl.gov> Message-ID: <453F8F0D.5030204@security.berkeley.edu> Matt, We are running a very similar configuration and are using netgraph to bond the two interfaces into one virtual interface which we monitor (again similar to your method) and it has been working fairly well for us. My understanding is that the kernel patch is no longer necessary because netgraph is already in the source code, it just needs to be compiled in by adding "options NETGRAPH" to the kernel config file and then running a script during startup that creates the virtual interface. The one problem I have seen with two of our systems is that the interface periodically goes deaf and doesn't come back unless with ifconfig down and up all of the interfaces involved (so I wrote a script that tests the interface every few minutes and restarts it and notifies me if there is no traffic). This only seems to happen on two or the 5 boxes I use this on (not the bro box), and I suspect it is partially a function of something else I may be running (or is based upon load). John Matt Cuttler wrote: > Ennobled bro users and developers, > > I'm looking for some clarification on the use of bro and multiple > interfaces. > > FreeBSD 6.1 machine with two em* (Intel 1000 fibre) interfaces. Each > interface's RX port is connected to one of the two TX ports on a > regenerative tap. > > Bro.cfg was originally configured as: > BRO_CAPTURE_INTERFACE="em0 em1" > > Additionally, we tried enabling and disabling: > BRO_BPFBOND_ENABLE="YES" > and > BRO_BPFBOND_FLAGS="em0 em1" > > In all cases above, we got indications that this configuration was not > correct, and that bro might not be getting all of the traffic across > both interfaces properly (see example #1 below, with content gaps in the > smtp log). > > We then set up a bond interface: > ifconfig bridge0 create > ifconfig bridge0 addm em0 addm em1 up > ..and changed our bro.cfg to: > BRO_CAPTURE_INTERFACE="bond0" > BRO_BPFBOND_ENABLE="NO" > > This seems to work properly now; at least we no longer get content gaps > logged to the smtp log (see example #2 below). > > My questions are: Is this (bridge device method) the "right" way to > handle multiple interfaces for my hardware/software? The documentation > mentions kernel patches to enable bpf bonding on FreeBSD 4.1. Is this > not necessary on later FreeBSD releases? > > Thanks, > Matt Cuttler > > === > example #1, using em0 and em1: > 1.2.3.4/1880 > 5.6.7.8/smtp start internal > 1.2.3.4/1880 > 5.6.7.8/smtp: unexpected: content gap: \ > seq = 30, len = 33 > 1.2.3.4/1880 < 5.6.7.8/smtp: unusual command/reply: \ > (UNKNOWN)() --> 250(OK) > 1.2.3.4/1880 > 5.6.7.8/smtp: unexpected: unexpected \ > command: RCPT reply = 0 state = 12 > 1.2.3.4/1880 < 5.6.7.8/smtp: unexpected: content gap: \ > seq = 139, len = 14 > 1.2.3.4/1880 < 5.6.7.8/smtp: unexpected: content gap: \ > seq = 153, len = 14 > 1.2.3.4/1880 < 5.6.7.8/smtp: unusual command/reply: \ > (UNKNOWN)() --> 250(Accepted) > 1.2.3.4/1880 > 5.6.7.8/smtp: unexpected: unexpected \ > command: DATA reply = 0 state = 12 > 1.2.3.4/1880 > 5.6.7.8/smtp: unexpected: content gap: \ > seq = 149, len = 1460 > 1.2.3.4/1880 > 5.6.7.8/smtp: unexpected: content gap: \ > seq = 1609, len = 1697 > 1.2.3.4/1880 < 5.6.7.8/smtp: unexpected: content gap: \ > seq = 237, len = 28 > 1.2.3.4/1880 < 5.6.7.8/smtp: unusual command/reply: \ > (UNKNOWN)() --> 221(mail.host.net closing connection) > finish > === > > === > Example #2, using bond0: > > 1.2.3.4/19100 > 5.6.7.8/smtp start external > recipient: > finish > > === > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > > > > -- ------------------------------------------------------------------------- John Ives Phone (510) 642-7773 GSEC, GCIH, GCWN Cell (510) 229-8676 System & Network Security University of California, Berkeley "If you spend more on coffee than on IT security, then you will be hacked. What's more, you deserve to be hacked." Richard Clarke (Former Special Advisor to the President on Cybersecurity) ------------------------------------------------------------------------- From mtdedlow at lbl.gov Wed Oct 25 10:12:04 2006 From: mtdedlow at lbl.gov (Mark Dedlow) Date: Wed, 25 Oct 2006 13:12:04 -0400 Subject: [Bro] bridge interface vs. bpf bonding (patch?) on FreeBSD 6.1 In-Reply-To: <453F8F0D.5030204@security.berkeley.edu> References: <453ECAF3.5060807@bnl.gov> <453F8F0D.5030204@security.berkeley.edu> Message-ID: <453F9AE4.1050302@lbl.gov> Matt, We also use netgraph, but don't have the same problems John has. Here's the netgraph config: # load module kldload ng_ether # bring up the real interfaces ifconfig em0 promisc -arp up ifconfig em1 promisc -arp up # create ngeth0 and bind em1 and em2 to it ngctl mkpeer . eiface hook ether ngctl mkpeer ngeth0: one2many lower one ngctl connect em0: ngeth0:lower lower many0 ngctl connect em1: ngeth0:lower lower many1 # bring up ngeth0 ifconfig ngeth0 -arp up Mark John Ives wrote: > Matt, > > We are running a very similar configuration and are using netgraph to > bond the two interfaces into one virtual interface which we monitor > (again similar to your method) and it has been working fairly well for > us. My understanding is that the kernel patch is no longer necessary > because netgraph is already in the source code, it just needs to be > compiled in by adding "options NETGRAPH" to the kernel config file and > then running a script during startup that creates the virtual > interface. The one problem I have seen with two of our systems is that > the interface periodically goes deaf and doesn't come back unless with > ifconfig down and up all of the interfaces involved (so I wrote a script > that tests the interface every few minutes and restarts it and notifies > me if there is no traffic). This only seems to happen on two or the 5 > boxes I use this on (not the bro box), and I suspect it is partially a > function of something else I may be running (or is based upon load). > > John > > Matt Cuttler wrote: >> Ennobled bro users and developers, >> >> I'm looking for some clarification on the use of bro and multiple >> interfaces. >> >> FreeBSD 6.1 machine with two em* (Intel 1000 fibre) interfaces. Each >> interface's RX port is connected to one of the two TX ports on a >> regenerative tap. >> >> Bro.cfg was originally configured as: >> BRO_CAPTURE_INTERFACE="em0 em1" >> >> Additionally, we tried enabling and disabling: >> BRO_BPFBOND_ENABLE="YES" >> and >> BRO_BPFBOND_FLAGS="em0 em1" >> >> In all cases above, we got indications that this configuration was not >> correct, and that bro might not be getting all of the traffic across >> both interfaces properly (see example #1 below, with content gaps in the >> smtp log). >> >> We then set up a bond interface: >> ifconfig bridge0 create >> ifconfig bridge0 addm em0 addm em1 up >> ..and changed our bro.cfg to: >> BRO_CAPTURE_INTERFACE="bond0" >> BRO_BPFBOND_ENABLE="NO" >> >> This seems to work properly now; at least we no longer get content gaps >> logged to the smtp log (see example #2 below). >> >> My questions are: Is this (bridge device method) the "right" way to >> handle multiple interfaces for my hardware/software? The documentation >> mentions kernel patches to enable bpf bonding on FreeBSD 4.1. Is this >> not necessary on later FreeBSD releases? >> >> Thanks, >> Matt Cuttler >> >> === >> example #1, using em0 and em1: >> 1.2.3.4/1880 > 5.6.7.8/smtp start internal >> 1.2.3.4/1880 > 5.6.7.8/smtp: unexpected: content gap: \ >> seq = 30, len = 33 >> 1.2.3.4/1880 < 5.6.7.8/smtp: unusual command/reply: \ >> (UNKNOWN)() --> 250(OK) >> 1.2.3.4/1880 > 5.6.7.8/smtp: unexpected: unexpected \ >> command: RCPT reply = 0 state = 12 >> 1.2.3.4/1880 < 5.6.7.8/smtp: unexpected: content gap: \ >> seq = 139, len = 14 >> 1.2.3.4/1880 < 5.6.7.8/smtp: unexpected: content gap: \ >> seq = 153, len = 14 >> 1.2.3.4/1880 < 5.6.7.8/smtp: unusual command/reply: \ >> (UNKNOWN)() --> 250(Accepted) >> 1.2.3.4/1880 > 5.6.7.8/smtp: unexpected: unexpected \ >> command: DATA reply = 0 state = 12 >> 1.2.3.4/1880 > 5.6.7.8/smtp: unexpected: content gap: \ >> seq = 149, len = 1460 >> 1.2.3.4/1880 > 5.6.7.8/smtp: unexpected: content gap: \ >> seq = 1609, len = 1697 >> 1.2.3.4/1880 < 5.6.7.8/smtp: unexpected: content gap: \ >> seq = 237, len = 28 >> 1.2.3.4/1880 < 5.6.7.8/smtp: unusual command/reply: \ >> (UNKNOWN)() --> 221(mail.host.net closing connection) >> finish >> === >> >> === >> Example #2, using bond0: >> >> 1.2.3.4/19100 > 5.6.7.8/smtp start external >> recipient: >> finish >> >> === >> _______________________________________________ >> Bro mailing list >> bro at bro-ids.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro >> >> >> >> > > From bltierney at lbl.gov Wed Oct 25 11:12:49 2006 From: bltierney at lbl.gov (Brian Tierney) Date: Wed, 25 Oct 2006 13:12:49 -0500 Subject: [Bro] bridge interface vs. bpf bonding (patch?) on FreeBSD 6.1 In-Reply-To: <453F8F0D.5030204@security.berkeley.edu> References: <453ECAF3.5060807@bnl.gov> <453F8F0D.5030204@security.berkeley.edu> Message-ID: <453FA921.8010302@lbl.gov> John Ives wrote: > Matt, > > > The one problem I have seen with two of our systems is that > the interface periodically goes deaf and doesn't come back unless with > ifconfig down and up all of the interfaces involved (so I wrote a script > that tests the interface every few minutes and restarts it and notifies > me if there is no traffic). I had this problem under FreeBSD 6.0, but it went away when I upgraded to 6.1 From jives at security.berkeley.edu Wed Oct 25 11:33:00 2006 From: jives at security.berkeley.edu (John Ives) Date: Wed, 25 Oct 2006 11:33:00 -0700 Subject: [Bro] bridge interface vs. bpf bonding (patch?) on FreeBSD 6.1 In-Reply-To: <453FA921.8010302@lbl.gov> References: <453ECAF3.5060807@bnl.gov> <453F8F0D.5030204@security.berkeley.edu> <453FA921.8010302@lbl.gov> Message-ID: <453FADDC.90007@security.berkeley.edu> Brian Tierney wrote: > John Ives wrote: > >> Matt, >> >> >>> The one problem I have seen with two of our systems is that >>> >> the interface periodically goes deaf and doesn't come back unless with >> ifconfig down and up all of the interfaces involved (so I wrote a script >> that tests the interface every few minutes and restarts it and notifies >> me if there is no traffic). >> > > I had this problem under FreeBSD 6.0, but it went away when I upgraded > to 6.1 > Thanks for confirming I am not crazy. :) Actually when I upgraded to 6.1 (rebuilt world) it got a lot better, but did not go away completely (whereas it hasn't been a problem the boxes that were built at 6.1 from the start). At some point I will probably just need to bite the bullet and rebuild the machines, but probably not until sometime after 6.2. John -- ------------------------------------------------------------------------- John Ives Phone (510) 642-7773 GSEC, GCIH, GCWN Cell (510) 229-8676 System & Network Security University of California, Berkeley ------------------------------------------------------------------------- From Marc.Weisbrod at ucsf.edu Thu Oct 26 16:15:07 2006 From: Marc.Weisbrod at ucsf.edu (Weisbrod, Marc) Date: Thu, 26 Oct 2006 16:15:07 -0700 Subject: [Bro] FW: ACLD implementation Message-ID: <84AB0D137E1C404DAF16B621C46701AA01C446FB@EXVS05.net.ucsf.edu> > All, > > I am having an issue getting ACLD working. I have expect and Acld is running on my system. When a "bad guy" is identified by Bro. It tries and shim in the ACL. When that occurs I see the following error: > > acl.sh: Oct 26 16:10:18 drop 2.2.2.2 > couldn't execute "socket": no such file or directoryerror setting blocking mode: resource temporarily unavailable > while executing > "spawn socket -c $aclipaddr $aclport" > (file "/usr/local/bro/bin/acl.sh" line 249) > > Am I missing a binary? Or could this be an old version of acl.sh? > > Thank you, > > Marc > > Marc Weisbrod > Senior Security Engineer > University of California, San Francisco > 1855 Folsom Street, Room 602 > San Francisco, CA 94103 > > > From jmellander at lbl.gov Thu Oct 26 16:24:13 2006 From: jmellander at lbl.gov (Jim Mellander) Date: Thu, 26 Oct 2006 16:24:13 -0700 Subject: [Bro] Bro trace files - packets truncated in some circumstances? In-Reply-To: <4540DEE5.2050807@lbl.gov> References: <453FBA78.20207@lbl.gov> <453FFE39.8000208@lbl.gov> <4540CB99.5010003@lbl.gov> <4540DEE5.2050807@lbl.gov> Message-ID: <4541439D.3060208@lbl.gov> I'm testing Bro on a 10 G link. In some cases, it seems that the tracefile created by Bro truncates the received packet. Here's an instance where the Bro running the 10G card cut off the packet early: >From Bro running on 10G: 1161587285.381234 128.3.7.51.80 > 66.94.232.246.46965: FP 2067756330:2067756438(108) ack 53063837 win 24616 (DF) 4500 00a0 e4dc 4000 3e06 a4f0 8003 0733 425e e8f6 0050 b775 7b3f 752a 0329 b09d 8019 6028 6a20 0000 0101 080a 4c04 19ca 2eaf 599f Bro running on 1G: 1161587285.381098 128.3.7.51.80 > 66.94.232.246.46965: FP 2067756330:2067756438(108) ack 53063837 win 24616 (DF) 4500 00a0 e4dc 4000 3e06 a4f0 8003 0733 425e e8f6 0050 b775 7b3f 752a 0329 b09d 8019 6028 6a20 0000 0101 080a 4c04 19ca 2eaf 599f 636b 7175 6f74 653e 3c2f 7464 3e0d 0a20 203c 2f74 723e 0d0a 3c2f 7461 626c 653e 0d0a 0d0a 3c70 3e3c 6120 6872 6566 3d22 2e2f 6c65 6164 5f65 7870 6f73 7572 652e 7368 746d 6c22 3e4e 6578 743e 3c2f 613e 0d0a 0909 0909 0909 0d0a 0d0a 3c2f 626f 6479 3e0d 0a3c 2f68 746d 6c3e Looking at other examples, it looks like Bro cuts off FIN's with data when recording packets, sometimes. I've seen this same effect on the 1 Gig traffic too, so I don't think it is a problem with the 10 G card. In the Bro code, TCP_Rewriter.cc, we see: void PacketDumper::DumpPacket(const struct pcap_pkthdr* hdr, const u_char* pkt, int len) { if ( pkt_dump ) { struct pcap_pkthdr h = *hdr; h.caplen = len; if ( h.caplen > hdr->caplen ) internal_error("bad modified caplen"); pcap_dump((u_char*) pkt_dump, &h, pkt); } } So it looks like if passed a smaller len than the original capture length, the output packet will be smaller than the original received packet. Does anyone know why this is being done? It would be nice if the entire packet was recorded.... -- Jim Mellander Incident Response Manager Computer Protection Program Lawrence Berkeley National Laboratory (510) 486-7204 The reason you are having computer problems is: Just type 'mv * /dev/null'. From ahutton at lbl.gov Thu Oct 26 16:40:14 2006 From: ahutton at lbl.gov (Anne Hutton) Date: Thu, 26 Oct 2006 16:40:14 -0700 Subject: [Bro] FW: ACLD implementation In-Reply-To: <84AB0D137E1C404DAF16B621C46701AA01C446FB@EXVS05.net.ucsf.edu> References: <84AB0D137E1C404DAF16B621C46701AA01C446FB@EXVS05.net.ucsf.edu> Message-ID: <4541475E.90001@lbl.gov> you need to install socket from /usr/ports/sysutils on freebsd.....or the package. Anne Weisbrod, Marc wrote: >> All, >> >> I am having an issue getting ACLD working. I have expect and Acld is running on my system. When a "bad guy" is identified by Bro. It tries and shim in the ACL. When that occurs I see the following error: >> >> acl.sh: Oct 26 16:10:18 drop 2.2.2.2 >> couldn't execute "socket": no such file or directoryerror setting blocking mode: resource temporarily unavailable >> while executing >> "spawn socket -c $aclipaddr $aclport" >> (file "/usr/local/bro/bin/acl.sh" line 249) >> >> Am I missing a binary? Or could this be an old version of acl.sh? >> >> Thank you, >> >> Marc >> >> Marc Weisbrod >> Senior Security Engineer >> University of California, San Francisco >> 1855 Folsom Street, Room 602 >> San Francisco, CA 94103 >> >> >> > > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > -- Anne Hutton Computer Protection Program Lawrence Berkeley National Lab 510-495-2681 From vern at icir.org Sat Oct 28 10:55:42 2006 From: vern at icir.org (Vern Paxson) Date: Sat, 28 Oct 2006 10:55:42 -0700 Subject: [Bro] Bro trace files - packets truncated in some circumstances? In-Reply-To: <4541439D.3060208@lbl.gov> (Thu, 26 Oct 2006 16:24:13 PDT). Message-ID: <200610281755.k9SHtgLv007879@jaguar.icir.org> > So it looks like if passed a smaller len than the original capture > length, the output packet will be smaller than the original received > packet. Does anyone know why this is being done? It would be nice if > the entire packet was recorded.... It's actually going out of its way to do this (in TCP.cc): // By default, if it's a TCP port 80 FIN packet, don't // record its contents. Eliminating these (unless we're // doing HTTP analysis) cuts the save file size by about // a factor of two, since often HTTP FIN packets have most // of the server reply in them. if ( flags.FIN() && dst_port == 80 ) Conn()->SetRecordContents(0); This is quite old code and (thanks to your flagging it) will be removed in the next release. Vern From adayadil.thomas at gmail.com Mon Oct 30 13:44:42 2006 From: adayadil.thomas at gmail.com (Adayadil Thomas) Date: Mon, 30 Oct 2006 16:44:42 -0500 Subject: [Bro] Bro and asymmetric routing Message-ID: Hello All I have a question about asymmetric routing and Bro IDS Consider a situation where a traffic to and from an organization takes different routes and the IDS is deployed where only one directional of the conversation can be monitored (either client to server OR server to client). In such a situation does the TCP analysis of Bro work ? or does it need to see both sides of the conversation ? Thanks for the reply. Thomas From dhanesh at tataelxsi.co.in Mon Oct 30 19:02:56 2006 From: dhanesh at tataelxsi.co.in (Jaya Dhanesh) Date: Tue, 31 Oct 2006 08:32:56 +0530 Subject: [Bro] Using a 'OR' condition in Signature payloads Message-ID: <000101c6fc99$117e3f00$0637a8c0@telxsi.com> Hi All, I was trying to implement an 'OR' condition in the signature payload to match either of the two patterns given in payload. For example: signature abc-21 { ip-proto == tcp . . . . . . . . payload /.*(abc) | (xyz).*/ } When I run Bro with this signature, I was able to see a log for the packet that matches the pattern first.i.e., the packet with abc or xyz (whichever comes first) gets logged and the rest doesn't generate a log. Only one pattern matches always and the others go unnoticed. Is there anything wrong in writing the 'OR' condition? Thanks in advance, Dhanesh. From vern at icir.org Mon Oct 30 19:08:37 2006 From: vern at icir.org (Vern Paxson) Date: Mon, 30 Oct 2006 19:08:37 -0800 Subject: [Bro] Using a 'OR' condition in Signature payloads In-Reply-To: <000101c6fc99$117e3f00$0637a8c0@telxsi.com> (Tue, 31 Oct 2006 08:32:56 +0530). Message-ID: <200610310308.k9V38brI048076@jaguar.icir.org> > payload /.*(abc) | (xyz).*/ > ... > Is there anything wrong in writing the 'OR' condition? Yes, this should be written instead as: payload /.*(abc)|(xyz).*/ Or, if you want to match "abc" or "xyz" anywhere in the payload, as: payload /.*(abc|xyz).*/ - Vern From dhanesh at tataelxsi.co.in Mon Oct 30 19:51:32 2006 From: dhanesh at tataelxsi.co.in (Jaya Dhanesh) Date: Tue, 31 Oct 2006 09:21:32 +0530 Subject: [Bro] Using a 'OR' condition in Signature payloads In-Reply-To: <200610310308.k9V38brI048076@jaguar.icir.org> Message-ID: <000601c6fc9f$db2bd3c0$0637a8c0@telxsi.com> Hi, >Yes, this should be written instead as: > payload /.*(abc)|(xyz).*/ >Or, if you want to match "abc" or "xyz" anywhere in the payload, as: > payload /.*(abc|xyz).*/ I wrote the same pattern in the payload, only the first packet that matches the pattern (either 'abc' or 'xyz')gets logged. Bro checks for the pattern in each packet, so I should have got logs for all the packets that has atleast one of the patterns. Dhanesh. From vern at icir.org Tue Oct 31 00:27:13 2006 From: vern at icir.org (Vern Paxson) Date: Tue, 31 Oct 2006 00:27:13 -0800 Subject: [Bro] Bro and asymmetric routing In-Reply-To: (Mon, 30 Oct 2006 16:44:42 EST). Message-ID: <200610310827.k9V8RDrZ056982@jaguar.icir.org> > In such a situation does the TCP analysis of Bro work ? or does it > need to see both sides of the conversation ? Bro has code to detect this case and still perform some analysis. However, we haven't operated it in such an environment for a number of years, so I don't know if that code still functions correctly. Even if it does, you'll still at best get degraded performance, since many of the policy scripts expect to match requests with responses. Vern From vern at icir.org Tue Oct 31 00:32:27 2006 From: vern at icir.org (Vern Paxson) Date: Tue, 31 Oct 2006 00:32:27 -0800 Subject: [Bro] Using a 'OR' condition in Signature payloads In-Reply-To: <000101c6fc99$117e3f00$0637a8c0@telxsi.com> (Tue, 31 Oct 2006 08:32:56 +0530). Message-ID: <200610310832.k9V8WRTl057109@jaguar.icir.org> > payload /.*(abc) | (xyz).*/ > } > > When I run Bro with this signature, I was able to see a log for the packet > that matches the pattern first.i.e., the packet with > abc or xyz (whichever comes first) gets logged and the rest doesn't generate > a log. > Only one pattern matches always and the others go unnoticed. > > Is there anything wrong in writing the 'OR' condition? I believe what's going on is that "payload" is matching the TCP *byte-stream* rather than individual packets. As such, there's just one match to the pattern, since the .*'s eat up everything else in the byte-stream. There's an option to just match packet payloads, but I don't recall what it is. I've cc'd Robin since he's the expert on the signature engine. Vern From serkra at lateko.lv Tue Oct 31 02:44:27 2006 From: serkra at lateko.lv (Sergejs Kravchenko) Date: Tue, 31 Oct 2006 12:44:27 +0200 Subject: [Bro] Bro Message-ID: <002701c6fcd9$8bfbde00$1f0f630a@ss> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20061031/dbb19f97/attachment.html From robin at icir.org Tue Oct 31 16:44:29 2006 From: robin at icir.org (Robin Sommer) Date: Tue, 31 Oct 2006 16:44:29 -0800 Subject: [Bro] Using a 'OR' condition in Signature payloads In-Reply-To: <200610310832.k9V8WRTl057109@jaguar.icir.org> References: <000101c6fc99$117e3f00$0637a8c0@telxsi.com> <200610310832.k9V8WRTl057109@jaguar.icir.org> Message-ID: <20061101004429.GA6896@icir.org> On Tue, Oct 31, 2006 at 00:32 -0800, Vern Paxson wrote: > I believe what's going on is that "payload" is matching the TCP *byte-stream* > rather than individual packets. As such, there's just one match to the > pattern, since the .*'s eat up everything else in the byte-stream. That's right. > There's an option to just match packet payloads, but I don't recall what > it is. No, there is no option (UDP is matched packet-wise but even for UDP Bro reports each signature-match only once per UDP flow). Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org LBNL/ICSI * Fax +1 (510) 666-2956 * www.icir.org