From christian@whoop.org Thu Sep 1 02:39:47 2005 From: christian@whoop.org (Christian Kreibich) Date: Wed, 31 Aug 2005 18:39:47 -0700 Subject: [Bro] Side effects on record fields when triggering events In-Reply-To: <200508310447.j7V4lQEd052838@jaguar.icir.org> References: <200508310447.j7V4lQEd052838@jaguar.icir.org> Message-ID: <1125538788.5492.112.camel@localhost> On Tue, 2005-08-30 at 21:47 -0700, Vern Paxson wrote: > > Okay Chema and I tracked it down to the reference counting that is going > > on in the core > > Exactly. Aggregates in Bro are passed as shallow copiess, not deep copies. > There are times when it would be handy to have an operator to specify > deep-copy semantics. I share your concern at the counter-intuitive behavior > that shallow-copy semantics can provide, but blanket deep-copy can be very > expensive, and needlessly so in many cases. Yeah I agree. It's also not too big a big deal if you have the way it works in mind while writing policy code. I think I'll grow your patch queue with some documentation. :) Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From vern@icir.org Thu Sep 1 07:36:29 2005 From: vern@icir.org (Vern Paxson) Date: Wed, 31 Aug 2005 23:36:29 -0700 Subject: [Bro] Bro install problems on linux In-Reply-To: Your message of Mon, 29 Aug 2005 16:38:32 PDT. Message-ID: <200509010636.j816aTNN082592@jaguar.icir.org> > Unless we > throw out the macro containers and switch to STL ones. What's your take > on this Vern? That's fine with me, though it'll be a fair amount of work due to the widespread use of the List/PList classes. > > I'm assuming this code was written before templates became practical in a Ohhhhh yes - that code is the oldest in the entire distribution, dating to 1985! It's amazed it still compiles :-). Vern From vern@icir.org Thu Sep 1 07:38:24 2005 From: vern@icir.org (Vern Paxson) Date: Wed, 31 Aug 2005 23:38:24 -0700 Subject: [Bro] Bro install problems on linux In-Reply-To: Your message of Tue, 30 Aug 2005 22:52:06 PDT. Message-ID: <200509010638.j816cOKp082671@jaguar.icir.org> > I'm attaching a patch for the 64-bit people out there to try. Thanks! I plan to integrate this (with a name change for intp), unless folks find it causes problems. Vern From vern@icir.org Wed Sep 7 06:26:15 2005 From: vern@icir.org (Vern Paxson) Date: Tue, 06 Sep 2005 22:26:15 -0700 Subject: [Bro] new Bro CURRENT release (0.9a10) In-Reply-To: Your message of Fri, 20 May 2005 00:16:14 PDT. Message-ID: <200509070526.j875QFnS069624@jaguar.icir.org> A new CURRENT release, 0.9a10, is now available from: ftp://bro-ids.org/bro-0.9-current.tar.gz This release primarily includes bug fixes and portability enhancements, though also some new features, per the appended. The next major release will have *extensive* additions, so I'm thinking that perhaps this will be the last 0.9 release, and will become the new STABLE distribution (assuming it proves to be stable over the coming months), though I haven't decided that for sure yet. Also note that this release marks a shift to a new FTP repository directly off of bro-ids.org. Vern -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0.9a10 Tue Sep 6 10:41:53 PDT 2005 - Fixes for portability to 64-bit architectures (Christian Kreibich). - Bug fix for broken syslog'ing of alarms (Scott Campbell). - The manual has been updated to clarify that aggregate values in events are passed as shallow copies, so that modifications to elements of the values after posting the event but before it's handled will be visible to the handlers for the events (Christian Kreibich). - HTTP logging now includes the host from the Host header in the request (Craig Leres). Note, currenty this only is done when using http-reply.bro, not if you only analyze requests. - You can now specify a passphrase for the SSL cert used for inter-Bro communication by redef'ing the variaable "ssl_passphrase" (Christian Kreibich). Leaving it unchanged causes the passphrase to be read interactively. - Certificates created using ca-issue now have 2-year lifetimes rather than the default of 30 days (Christian Kreibich). - A problem with handshaking between Bro peers has been fixed (Christian Kreibich). - A bug has been fixed in scanning false positives due to backscatter in the form of SYN ACKs (Vern Paxson). - Alerts sent via email now use a From address configured from bro.cfg (Randy Mcclelland-Bane). Also, if sending an alert via gpg fails, it's sent instead as plaintext. - Scan notices now include information about the connection that triggered the scan detection decision (Vern Paxson). - Exported some TRW variables so the user can adjust their associated timers (Vern Paxson). - The new script variable dns_max_queries sets a maximum on the number of queries that can appear in a DNS request (Scott Campbell & Vern Paxson). If more queries appear, the request is treated as non-DNS traffic and ignored. The variable defaults to a value of 5. Setting it to 0 turns off this functionality, so Bro processes all apparent requests. - The "weird" messages generated by the DNS analyzer now have a more regular naming structure and processing (Scott Campbell and Vern Paxson). - Tweaked bif_arg.cc to pass gcc4.0 and bro.bif to not collide with uuid in OSX 10.4 (Jason Lee). Now works on OSX 10.4, though use --disable-localpcap when compiling. - Bro now compiles cleanly under OpenBSD (Jason Lee). - NOTE: the connection compressor has a known serious bug and should not be used at present. Since it is an experimental feature, fixing it is deferred to the next release. - Some bugs fixed in the management of hash keys when using the connection compressor (Robin Sommer). - Tweak for the connection compressor to generate truncated_header weird's (Robin Sommer). - Temporary bug fix for type clash in SSL version numbers (Vern Paxson) by making them consistently of type int. The correct fix is probably for them to be consistently of type count, depending on how Bro's notion of general version processing, and its SSL analyzer, both evolve. - Bug fix for trace rewriting failing if Bro was not compiled to check assertions (Martin Casado). - Fixed logic bug in signal handling regarding whether we're currently idle waiting for input vs. processing a packet or the event queue (Vern Paxson). Note, this change has not been heavily tested. - Some bug fixes for correct operation when DNS names fail to resolve (Vern Paxson). It's not clear that these fixes are complete, however. - Fixed to not compile libpcap when --disable-localpcap is given to configure (Jason Lee). - Fixed configuration of local pcap for IPv6 if --enable-brov6 is specified (Jason Lee). - A problem with "make install" when building from the libpcap included in the sources has been fixed (Christian Kreibich). From chema@cs.berkeley.edu Sat Sep 10 23:32:02 2005 From: chema@cs.berkeley.edu (Jose M. Gonzalez) Date: Sat, 10 Sep 2005 15:32:02 -0700 Subject: [Bro] Bug on Anon.cc Message-ID: <20050910223202.GA20377@cs.berkeley.edu> --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I think I found a bug in the IP anonymizer code, more concretely in the PREFIX_PRESERVING_MD5 mode (well, considering that the anonymized addresses do not preserve prefixes, I'd say it is a bug). I include a patch. -Chema --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bro.current.20050910.fix_for_ip_anonymizer_in_mode_preserving_md5.diff" Index: Anon.cc =================================================================== RCS file: /home/portnoy/u2/src/projects/bro/src/Anon.cc,v retrieving revision 1.1 diff -r1.1 Anon.cc 101a102,107 > /* > * this code is from "On the Design and Performance of Prefix-Preserving > * IP Traffic Trace Anonymization", by Xu et al (IMW 2001) > * > * http://www.imconf.net/imw-2001/proceedings.html > */ 105a112 > input = ntohl(input); 110,111c117,119 < prefix.len = 32 - i; < prefix.prefix = input & prefix_mask; --- > /* PAD(x_0 ... x_{i-1}) = x_0 ... x_{i-1} 0 ... 0 */ > prefix.len = 31 - i; > prefix.prefix = input & ~(prefix_mask>>prefix.len); 113c121,122 < hmac_md5(sizeof(prefix), (u_char*)(&prefix), digest); --- > /* HK(PAD(x_0 ... x_{i-1})) */ > hmac_md5(sizeof(prefix.prefix), (u_char*)(&prefix.prefix), digest); 114a124 > /* f_{i-1} = LSB(HK(PAD(x_0 ... x_{i-1}))) */ 115a126,127 > > /* x_i' = x_i ^ f_{i-1} */ 119c131 < return output; --- > return htonl(output); --+HP7ph2BbKc20aGI-- From chema@cs.berkeley.edu Sun Sep 11 01:53:50 2005 From: chema@cs.berkeley.edu (Jose M. Gonzalez) Date: Sat, 10 Sep 2005 17:53:50 -0700 Subject: [Bro] Re: Bug on Anon.cc In-Reply-To: <20050910223202.GA20377@cs.berkeley.edu> References: <20050910223202.GA20377@cs.berkeley.edu> Message-ID: <20050911005350.GA21577@cs.berkeley.edu> --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline FYI, the IP anonymizer code in mode PREFIX_PRESERVING_MD5 didn't do what it was supposed to do. Such mode is based on "On the Design and Performance of Prefix-Preserving IP Traffic Trace Anonymization", by Xu et al (IMW 2001), where it is suggested to anonymize X=x_0...x_{n-1} as X'=x'_0...x'_{n-1}, where: x_i' = x_i ^ f_{i-1}, f_{i-1} = LSB(HK(PAD(x_0 ... x_{i-1}), hashkey)) LSB: less significative bit function HK: cryptographic hash function (using hashkey) PAD(x_0 ... x_{i-1}) = x_0 ... x_{i-1} 0 ... 0 Two bugs in the old code: (a) it used addresses in network order, so prefixes didn't make too much sense. (b) it did the hash of an 8-byte struct composed of the prefix length and the input, instead of the prefix of the input (4 bytes). I also added some comments explaining the function. -Chema PS: The patch didn't include context. I enclose a context patch. I wrote: > Hi, > > I think I found a bug in the IP anonymizer code, more concretely in > the PREFIX_PRESERVING_MD5 mode (well, considering that the anonymized > addresses do not preserve prefixes, I'd say it is a bug). I include > a patch. > > -Chema > --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bro.current.20050910.fix_for_ip_anonymizer_in_mode_preserving_md5.diff" Index: Anon.cc =================================================================== RCS file: /home/portnoy/u2/src/projects/bro/src/Anon.cc,v retrieving revision 1.1 diff -u -r1.1 Anon.cc --- Anon.cc 14 Jul 2004 20:15:39 -0000 1.1 +++ Anon.cc 11 Sep 2005 00:43:04 -0000 @@ -99,24 +99,36 @@ return output; } +/* + * this code is from "On the Design and Performance of Prefix-Preserving + * IP Traffic Trace Anonymization", by Xu et al (IMW 2001) + * + * http://www.imconf.net/imw-2001/proceedings.html + */ ipaddr32_t AnonymizeIPAddr_PrefixMD5::anonymize(ipaddr32_t input) { uint8 digest[16]; ipaddr32_t prefix_mask = 0xffffffff; + input = ntohl(input); ipaddr32_t output = input; for ( int i = 0; i < 32; ++i ) { - prefix.len = 32 - i; - prefix.prefix = input & prefix_mask; + /* PAD(x_0 ... x_{i-1}) = x_0 ... x_{i-1} 0 ... 0 */ + prefix.len = 31 - i; + prefix.prefix = input & ~(prefix_mask>>prefix.len); - hmac_md5(sizeof(prefix), (u_char*)(&prefix), digest); + /* HK(PAD(x_0 ... x_{i-1})) */ + hmac_md5(sizeof(prefix.prefix), (u_char*)(&prefix.prefix), digest); + /* f_{i-1} = LSB(HK(PAD(x_0 ... x_{i-1}))) */ ipaddr32_t bit_mask = (digest[0] & 1) << i; + + /* x_i' = x_i ^ f_{i-1} */ output ^= bit_mask; } - return output; + return htonl(output); } AnonymizeIPAddr_A50::~AnonymizeIPAddr_A50() --fdj2RfSjLxBAspz7-- From rpang@cs.princeton.edu Sun Sep 11 04:25:29 2005 From: rpang@cs.princeton.edu (Ruoming Pang) Date: Sat, 10 Sep 2005 23:25:29 -0400 Subject: [Bro] Re: Bug on Anon.cc In-Reply-To: <20050911005350.GA21577@cs.berkeley.edu> References: <20050910223202.GA20377@cs.berkeley.edu> <20050911005350.GA21577@cs.berkeley.edu> Message-ID: > FYI, the IP anonymizer code in mode PREFIX_PRESERVING_MD5 didn't do > what it was supposed to do. Such mode is based on "On the Design and > Performance of Prefix-Preserving IP Traffic Trace Anonymization", by > Xu et al (IMW 2001), where it is suggested to anonymize > X=x_0...x_{n-1} as X'=x'_0...x'_{n-1}, where: > x_i' = x_i ^ f_{i-1}, > f_{i-1} = LSB(HK(PAD(x_0 ... x_{i-1}), hashkey)) > LSB: less significative bit function > HK: cryptographic hash function (using hashkey) > PAD(x_0 ... x_{i-1}) = x_0 ... x_{i-1} 0 ... 0 > > Two bugs in the old code: (a) it used addresses in network order, so > prefixes didn't make too much sense. That's right. I forgot to add an ntohl. Thanks for finding it! > (b) it did the hash of an 8-byte > struct composed of the prefix length and the input, instead of the > prefix of the input (4 bytes). I think this is not correct. For example, prefix 10.0.0.0/8 is different from 10.0.0.0/9, and should be hashed differently; otherwise the 9th and 10th most significant bits will always be flipped the same way. (Or, try to anonymize 128.0.0.0 with 1000 different keys, and see how many distinct results one can get.) Ruoming From chema@cs.berkeley.edu Sun Sep 11 05:06:46 2005 From: chema@cs.berkeley.edu (Jose M. Gonzalez) Date: Sat, 10 Sep 2005 21:06:46 -0700 Subject: [Bro] Re: Bug on Anon.cc In-Reply-To: References: <20050910223202.GA20377@cs.berkeley.edu> <20050911005350.GA21577@cs.berkeley.edu> Message-ID: <20050911040645.GA22934@cs.berkeley.edu> Ruoming Pang wrote: > >(b) it did the hash of an 8-byte > >struct composed of the prefix length and the input, instead of the > >prefix of the input (4 bytes). > I think this is not correct. For example, prefix 10.0.0.0/8 is > different from 10.0.0.0/9, and should be hashed differently; otherwise If you add the prefix length, then you have a "fixed-prefix length anonymizer." By this, I mean an anonymizer for each /X class. It's equivalent to have a hash key for /4 addresses, and another for /5 addresses. This scheme only preserves prefixes when the /X suffix is the same. For example, 10.0.0.0/8 and 10.0.0.0/9 will not have the same prefix. Is this what the function is supposed to do? With this scheme, you may also have collisions. It may be the case that 0.0.0.0/24 hashes to 4.4.4.0/24, and that 255.255.0.0/16 hashes to 4.4.0.0/16. The hashed addresses share a 16-bit prefix, while the input addresses share no prefix. BTW, if this is the case, for the code to work, you cannot change prefix.len during the "for" loop in AnonymizeIPAddr_PrefixMD5::anonymize(). > the 9th and 10th most significant bits will always be flipped the same > way. (Or, try to anonymize 128.0.0.0 with 1000 different keys, and see > how many distinct results one can get.) That's an artifact of the padding being 0...0. The f_0 function is a constant dependent on the hash key, so x'_0 is random. x'_1 to x'_{31} are all the same, as PAD(x_0) = PAD(x_0 x_1) = ... = PAD(x_0 ... x_{31}). Therefore, you can get 0.0.0.0, 128.0.0.0, 127.255.255.255, and 255.255.255.255. -Chema From rpang@cs.princeton.edu Sun Sep 11 16:12:27 2005 From: rpang@cs.princeton.edu (Ruoming Pang) Date: Sun, 11 Sep 2005 11:12:27 -0400 Subject: [Bro] Re: Bug on Anon.cc In-Reply-To: <20050911040645.GA22934@cs.berkeley.edu> References: <20050910223202.GA20377@cs.berkeley.edu> <20050911005350.GA21577@cs.berkeley.edu> <20050911040645.GA22934@cs.berkeley.edu> Message-ID: > Ruoming Pang wrote: >>> (b) it did the hash of an 8-byte >>> struct composed of the prefix length and the input, instead of the >>> prefix of the input (4 bytes). >> I think this is not correct. For example, prefix 10.0.0.0/8 is >> different from 10.0.0.0/9, and should be hashed differently; otherwise > If you add the prefix length, then you have a "fixed-prefix length > anonymizer." By this, I mean an anonymizer for each /X class. It's > equivalent to have a hash key for /4 addresses, and another for /5 > addresses. This scheme only preserves prefixes when the /X suffix is > the same. For example, 10.0.0.0/8 and 10.0.0.0/9 will not have the > same prefix. Is this what the function is supposed to do? I see. There is some misunderstanding here. We do not take the hash value of 10.0.0.0/8 as the result prefix, but use it to determine whether we flip the 9th bit. And hash value of 10.0.0.0/9 determines whether to flip the 10th bit, and so on. For your reference, the paper by Xu et. al. can be found at: http://www.imconf.net/imw-2001/imw2001-papers/69.ps.gz. >> (Or, try to anonymize 128.0.0.0 with 1000 different keys, and see >> how many distinct results one can get.) > That's an artifact of the padding being 0...0. The f_0 function is > a constant dependent on the hash key, so x'_0 is random. x'_1 to > x'_{31} are all the same, as PAD(x_0) = PAD(x_0 x_1) = ... = > PAD(x_0 ... x_{31}). By the way, the PAD function in the paper does include the prefix length, instead of padding with only 0. Ruoming From chema@cs.berkeley.edu Sun Sep 11 22:59:10 2005 From: chema@cs.berkeley.edu (Jose M. Gonzalez) Date: Sun, 11 Sep 2005 14:59:10 -0700 Subject: [Bro] Re: Bug on Anon.cc In-Reply-To: References: <20050910223202.GA20377@cs.berkeley.edu> <20050911005350.GA21577@cs.berkeley.edu> <20050911040645.GA22934@cs.berkeley.edu> Message-ID: <20050911215910.GA15953@cs.berkeley.edu> --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Ruoming Pang wrote: > I see. There is some misunderstanding here. We do not take the hash > value of 10.0.0.0/8 as the result prefix, but use it to determine > whether we flip the 9th bit. And hash value of 10.0.0.0/9 determines > whether to flip the 10th bit, and so on. Oh, I thought you were meaning that you wanted to anonymize the prefix 10.0.0.0/8, as compared to the address 10.0.0.0, from which hashing 10.0.0.0/8 is one of 32 steps. I'd say the discussion concerns only the padding function, which was wrong in both the old code and my patch. > By the way, the PAD function in the paper does include the prefix > length, instead of padding with only 0. You're right: the padding requires adding the $i$ value (the prefix length). That's actually what makes 128.0.0.0 hash to something different than 4 possible values. Still, you have to get rid of all the bits after the prefix you're currently hashing. Moreover, the padding also includes a 1 before the zeros (the padding is the same than in RFC 1321. I wonder which is the reason for adding a 1. Anyway, I'd respect it). For the old code, the prefix should be calculated as: prefix.prefix = (input & ~(prefix_mask>>(31-i))) | (1<>i)) | (1<<(31-i)); + /* HK(PAD(x_0 ... x_{i-1})) */ hmac_md5(sizeof(prefix), (u_char*)(&prefix), digest); - ipaddr32_t bit_mask = (digest[0] & 1) << i; + /* f_{i-1} = LSB(HK(PAD(x_0 ... x_{i-1}))) */ + ipaddr32_t bit_mask = (digest[0] & 1) << (31-i); + + /* x_i' = x_i ^ f_{i-1} */ output ^= bit_mask; } - return output; + return htonl(output); } AnonymizeIPAddr_A50::~AnonymizeIPAddr_A50() --Dxnq1zWXvFF0Q93v-- From rpang@cs.princeton.edu Mon Sep 12 03:15:54 2005 From: rpang@cs.princeton.edu (Ruoming Pang) Date: Sun, 11 Sep 2005 22:15:54 -0400 Subject: [Bro] Re: Bug on Anon.cc In-Reply-To: <20050911215910.GA15953@cs.berkeley.edu> References: <20050910223202.GA20377@cs.berkeley.edu> <20050911005350.GA21577@cs.berkeley.edu> <20050911040645.GA22934@cs.berkeley.edu> <20050911215910.GA15953@cs.berkeley.edu> Message-ID: <3efe494986f58c444f6a05a21ae88c69@cs.princeton.edu> > You're right: the padding requires adding the $i$ value (the prefix > length). That's actually what makes 128.0.0.0 hash to something > different than 4 possible values. I'm glad that now we agree upon this. > Still, you have to get rid of all the bits after the prefix you're > currently hashing. Yes, that's another bug in my old code, which, apparently, wasn't well tested. :-( > Moreover, the padding also includes a 1 before the > zeros (the padding is the same than in RFC 1321. I wonder which is > the reason for adding a 1. Anyway, I'd respect it). That is fine. > The code would be now OK. A minor quirk: the way the old code uses $i$ > is different from the way the paper uses $i$ (they are related as > $i_{paper} = 31 - i_{old_code}$). I changed the old code so that $i$ > is now the same than in the paper. Patch is enclosed. That's fine, too. However, there's another minor tweak we need to make (I learned that in writing and testing the same anonymization function in the TCPMKPUB code). The byte-by-byte value of struct prefix currently depends on byte order of the machine. In order for Bro to produce the same results for both byte orders, we have to put the 32 bit values back to network order when assigning the struct prefix. Thanks for looking into the code and finding the bugs! Ruoming From chema@cs.berkeley.edu Mon Sep 12 05:09:45 2005 From: chema@cs.berkeley.edu (Jose M. Gonzalez) Date: Sun, 11 Sep 2005 21:09:45 -0700 Subject: [Bro] Re: Bug on Anon.cc In-Reply-To: <3efe494986f58c444f6a05a21ae88c69@cs.princeton.edu> References: <20050910223202.GA20377@cs.berkeley.edu> <20050911005350.GA21577@cs.berkeley.edu> <20050911040645.GA22934@cs.berkeley.edu> <20050911215910.GA15953@cs.berkeley.edu> <3efe494986f58c444f6a05a21ae88c69@cs.princeton.edu> Message-ID: <20050912040945.GA18406@cs.berkeley.edu> --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Ruoming Pang wrote: > However, there's another minor tweak we need to make (I learned that in > writing and testing the same anonymization function in the TCPMKPUB > code). The byte-by-byte value of struct prefix currently depends on > byte order of the machine. In order for Bro to produce the same results > for both byte orders, we have to put the 32 bit values back to network > order when assigning the struct prefix. That's right. I enclose the patch. -Chema --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bro.current.20050910.fix_for_ip_anonymizer_in_mode_preserving_md5.diff" Index: Anon.cc =================================================================== RCS file: /home/portnoy/u2/src/projects/bro/src/Anon.cc,v retrieving revision 1.1 diff -u -r1.1 Anon.cc --- Anon.cc 14 Jul 2004 20:15:39 -0000 1.1 +++ Anon.cc 12 Sep 2005 04:07:52 -0000 @@ -99,24 +99,36 @@ return output; } +/* + * this code is from "On the Design and Performance of Prefix-Preserving + * IP Traffic Trace Anonymization", by Xu et al (IMW 2001) + * + * http://www.imconf.net/imw-2001/proceedings.html + */ ipaddr32_t AnonymizeIPAddr_PrefixMD5::anonymize(ipaddr32_t input) { uint8 digest[16]; ipaddr32_t prefix_mask = 0xffffffff; + input = ntohl(input); ipaddr32_t output = input; for ( int i = 0; i < 32; ++i ) { - prefix.len = 32 - i; - prefix.prefix = input & prefix_mask; + /* PAD(x_0 ... x_{i-1}) = x_0 ... x_{i-1} 1 0 ... 0 */ + prefix.len = htonl(i + 1); + prefix.prefix = htonl((input & ~(prefix_mask>>i)) | (1<<(31-i))); + /* HK(PAD(x_0 ... x_{i-1})) */ hmac_md5(sizeof(prefix), (u_char*)(&prefix), digest); - ipaddr32_t bit_mask = (digest[0] & 1) << i; + /* f_{i-1} = LSB(HK(PAD(x_0 ... x_{i-1}))) */ + ipaddr32_t bit_mask = (digest[0] & 1) << (31-i); + + /* x_i' = x_i ^ f_{i-1} */ output ^= bit_mask; } - return output; + return htonl(output); } AnonymizeIPAddr_A50::~AnonymizeIPAddr_A50() --2fHTh5uZTiUOsy+g-- From nuno_romano@yahoo.com Tue Sep 13 01:01:21 2005 From: nuno_romano@yahoo.com (nuno romano) Date: Mon, 12 Sep 2005 17:01:21 -0700 (PDT) Subject: [Bro] 1)Bro binary 2)Bro position in IDSs models Message-ID: <20050913000121.50881.qmail@web51314.mail.yahoo.com> 1) I got a bro binary of the 0.9 version,approximately 22 Megabytes.I compiled in Debian3.1,PowerPC,with a straightforward ./configure make.All seemed normal during the compilation.At first sight it seems a working binary.So,do I have a statically linked binary,with the overweight of the statically linked libraries? 2) In a paper(2003) called "The Intelligent IDS:The Next Generation of Intrusion Detection Management Revealed" Andre Yee of NFR Security Inc. positioned the ISS and NFR IDSs high,in both detection models: Protocol Anomaly Detection and Pattern Matching (a logical assumption in its position.).How do the Bro IDS position in these models?For Bro users who have a general knowledge about ISS and NFR IDSs. ______________________________________________________ Yahoo! for Good Donate to the Hurricane Katrina relief effort. http://store.yahoo.com/redcross-donate3/ From bro@grid.einherjar.de Tue Sep 13 08:43:00 2005 From: bro@grid.einherjar.de (Thorolf) Date: Tue, 13 Sep 2005 09:43:00 +0200 (CEST) Subject: [Bro] new Bro CURRENT release (0.9a10) In-Reply-To: <200509070526.j875QFnS069624@jaguar.icir.org> References: <200509070526.j875QFnS069624@jaguar.icir.org> Message-ID: <20050913094112.J638@verdandi.nat> Hi list, I'm glad to here that new version is out, but can someone add this to the cvs-repository? It's small bug ;-) ---- snip old mail > #11 0x804d39b in termination_signal () at main.cc:237 > 237 message("received termination signal"); > #12 0x804d41b in sig_handler (signo=15) at main.cc:264 > 264 termination_signal(); > #13 0xbfbfffac in ?? () > #14 0x284ba4cd in isatty () from /usr/lib/libc.so.4 > #15 0x284babe5 in malloc () from /usr/lib/libc.so.4 > #16 0x813ec21 in BaseList::BaseList (this=0xde24cc4, size=0) at util.h:217 > 217 void* ptr = malloc(size); It looks, ironically, that what's crashing Bro is its attempt to print out "received termination signal", with the problem being that malloc() is not reentrant, and the signal is occurring (and hence the printing happens) during a call to malloc(). Printing using printf can involve malloc() since it's used internally by the library. Try removing the line message("received termination signal"); from line 237 of main.cc and see if that makes the problem go away. Vern ---- snip old mail Do you plan to make cvs-repository available for anyone (read-only of course ;-)? Or at least do you plan to make something like hot-fix-patches for last released version? Regards, Rafal Lesniak - -- - - Run for your lives, death has arrived - - Try save your soul, run from the sound of rowing oars From christian@whoop.org Tue Sep 13 19:32:29 2005 From: christian@whoop.org (Christian Kreibich) Date: Tue, 13 Sep 2005 11:32:29 -0700 Subject: [Bro] 1)Bro binary 2)Bro position in IDSs models In-Reply-To: <20050913000121.50881.qmail@web51314.mail.yahoo.com> References: <20050913000121.50881.qmail@web51314.mail.yahoo.com> Message-ID: <1126636349.27509.187.camel@localhost> On Mon, 2005-09-12 at 17:01 -0700, nuno romano wrote: > 1) > > I got a bro binary of the 0.9 version,approximately > 22 Megabytes.I compiled in Debian3.1,PowerPC,with a > straightforward ./configure make.All seemed normal > during the compilation.At first sight it seems a > working > binary.So,do I have a statically linked binary,with > the > overweight of the statically linked libraries? That sounds awfully big. Can you post the output of your configure run, please? > 2) > > In a paper(2003) called "The Intelligent IDS:The > Next Generation of Intrusion Detection Management > Revealed" Andre Yee of NFR Security Inc. positioned > the ISS and NFR IDSs high,in both detection models: > Protocol Anomaly Detection and Pattern Matching > (a logical assumption in its position.).How do > the Bro IDS position in these models?For Bro > users who have a general knowledge about ISS and > NFR IDSs. The short answer is "Bro can do both." Its model is more general than any single category -- remote or local Bro nodes feed events into policy scripts that are provided in the distribution and adapted to your needs, or implemented from scratch by you. By configuring the handling of these events accordingly, you can realize pretty much any network-based intrusion detection model. The range of events provided gives you all the building blocks needed for both protocol anomaly detection and pattern matching. Please refer to the website & the manuals for more information. Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From mike.muratet@torchtechnologies.com Wed Sep 14 16:53:08 2005 From: mike.muratet@torchtechnologies.com (Mike Muratet) Date: Wed, 14 Sep 2005 10:53:08 -0500 Subject: [Bro] Broccoli and Intrusion Detection Exchange Format Message-ID: <008701c5b944$67b9ed40$5501a8c0@muratet> Greetings I discovered on the IETF website that there is an emerging standard for IDS message exchange. Not yet having read the standard, and being barely familiar with broccoli internals, I was curious: are there plans to have broccoli conform to any such standard? Thanks Mike From vern@icir.org Wed Sep 14 22:11:18 2005 From: vern@icir.org (Vern Paxson) Date: Wed, 14 Sep 2005 14:11:18 -0700 Subject: [Bro] Broccoli and Intrusion Detection Exchange Format In-Reply-To: Your message of Wed, 14 Sep 2005 10:53:08 CDT. Message-ID: <200509142111.j8ELBIcH031780@jaguar.icir.org> FYI, there are some hooks for IDMEF support within Bro itself (see #ifdef USE_IDMEF), but it's not complete. Broccoli doesn't have any IDMEF support, and in fact I don't believe it would be a fit for it to do so - IDMEF is for exchanging alerts, while Broccoli aims for exchanging events and typed values, which are much more general. Vern From christian@whoop.org Wed Sep 14 23:35:04 2005 From: christian@whoop.org (Christian Kreibich) Date: Wed, 14 Sep 2005 15:35:04 -0700 Subject: [Bro] Broccoli and Intrusion Detection Exchange Format In-Reply-To: <200509142111.j8ELBIcH031780@jaguar.icir.org> References: <200509142111.j8ELBIcH031780@jaguar.icir.org> Message-ID: <1126737305.27509.298.camel@localhost> On Wed, 2005-09-14 at 14:11 -0700, Vern Paxson wrote: > FYI, there are some hooks for IDMEF support within Bro itself (see #ifdef > USE_IDMEF), but it's not complete. Broccoli doesn't have any IDMEF support, > and in fact I don't believe it would be a fit for it to do so - IDMEF is > for exchanging alerts, while Broccoli aims for exchanging events and typed > values, which are much more general. Indeed. Broccoli is the wrong level of abstraction for IDMEF. Either use Broccoli to feed events into a Bro and have the Bro node generate IDMEF alerts, or write your own application that uses Broccoli for inter-Bro communication and something like libidmef to communicate alerts. Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From chema@cs.berkeley.edu Thu Sep 15 04:43:48 2005 From: chema@cs.berkeley.edu (Jose M. Gonzalez) Date: Wed, 14 Sep 2005 20:43:48 -0700 Subject: [Bro] Bug on PktSrc.cc Message-ID: <20050915034347.GA29683@cs.berkeley.edu> --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I think I found a weird bug in PktSrc.cc, related to the libpcap version Bro ships. The version of the arithmetic operation block generator we ship ( libpcap-0.7.2:gencode.c:get_arth() ) has a well-known bug [1], which makes gencode() punt when the filter being compiled has too many arithmetic operations. When this happens, PktSrc::PrecompileFilter() returns 0 (BPF_Program::Compile() returns false and fills the errbuf), but this is not caught by neither PktInterfaceSrc::PktInterfaceSrc() nor PktFileSrc::PktFileSrc(). Eventually Bro dies, with an unrelated message. If you want to test this, the following filter produces a weird error message. ((tcp[(ip[2:2] - ((ip[0]&0x0f)<<2))-1] == 0) and ((ip[2:2] - ((ip[0]&0x0f)<<2) - (tcp[12]>>2)) != 0) and ((ip[2:2] - ((ip[0]&0x0f)<<2) - (tcp[12]>>2)) <= 512)) or ( tcp[(tcp[12]>>2):4] = 0x5353482D and ( tcp[((tcp[12]>>2)+4):2] = 0x312e or tcp[((tcp[12]>>2)+4):2] = 0x322e)) I enclose a patch for Bro to die with a better error message. The patch to fix pcap is in [1] -Chema [1] http://www.tcpdump.org/lists/workers/2002/04/msg00014.html --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="bro.current.20050914.fix_for_wrong_filter_detection.diff" Index: PktSrc.cc =================================================================== RCS file: /home/portnoy/u2/src/projects/bro/src/PktSrc.cc,v retrieving revision 1.15 diff -u -r1.15 PktSrc.cc --- PktSrc.cc 12 Sep 2005 21:04:57 -0000 1.15 +++ PktSrc.cc 15 Sep 2005 03:37:50 -0000 @@ -386,6 +386,8 @@ SetHdrSize(); fprintf(stderr, "listening on %s\n", interface); } + else + closed = true; } @@ -399,11 +401,10 @@ pd = pcap_open_offline((char*) readfile, errbuf); - if ( ! pd ) - closed = true; - if ( pd && PrecompileFilter(0, filter) && SetFilter(0) ) SetHdrSize(); + else + closed = true; #ifdef USE_SELECT_LOOP // We don't put file sources into non-blocking mode as otherwise --1yeeQ81UyVL57Vl7-- From wsffree@hotmail.com Thu Sep 15 16:45:43 2005 From: wsffree@hotmail.com (Shaofu Wang) Date: Thu, 15 Sep 2005 15:45:43 +0000 Subject: [Bro] Please help me take back password of wsffly@sohu.com Message-ID:
Hi All
 
 
     After many failure, I must turn to you to help me take back
password of wsffly@sohu.com
 
pop3: pop3.sohu.com
stmp: stmp.sohu.com
 
   I promise the email is mine. Following is some mail in wsffly@sohu.com
 
    Please Please Please do help me.
   Looking forward your return.
 
Have a nice day!
--Shaofu Wang
 
 
+++++++++++++++++++++
subject:   RE: your job application
time:      2005-1-26 13:32:59
from:     Joerg Winkler<jw1@ttpcom.com>

Hi Shaofu Wang,
I will call you at 12.00pm (noon) this Friday for about
half an hour.
Best regards,
Joerg Winkler
> -----Original Message-----
> From: wsffly@sohu.com [mailto:wsffly@sohu.com]
> Sent: Tuesday, January 25, 2005 8:18 PM
> To: jw1@ttpcom.com
> Subject: Re:your job application
>
>
>  Hi Joerg Winkler,
>
>      Thank you so much for the chance, you give me!
>
>      I accept your suggestion. My lunch break time (every day) and
>
> Friday evening, is available. Just call me at your appropriate time.
>
> And my number is 0011-86-13688859080 (It is CMCC number,13688859080).
>
>
> Best regards,
>
> sincerely.
>
> --Shaofu Wang
>
>
>
> >
> >
> >
> > I would like to have a phone interview with you to discuss your
> > opportunities
> >
> > in TTPCOM. Since you apply from a customer I would like that you are not
> >
> > within Soutec during the interview. I therefore suggest that we have the
> >
> > interview preferably during your lunch break or in the evening this
> week.
> >
> > At lunch time I am available the whole week, in the evenings only on
> > Thursday
> >
> > or Friday. Please let me know when it suites you and the phone number
> >
> > I should call you on.
> >
> >
> >
> > Best regards,
> >
> > Joerg Winkler
> >
> >
> >
> > TTPCOM Singapore
> >
> > Tel +65 62265250 (office)
> >
>
 

 
 
+++++++++++++++++++++
(Read In Chinese , Please)
 
subject:  Fw: 对理论根据的完善
time:     2004-4-2 16:01:42
from:    Ju Jiubin<jjb@mail.jlu.edu.cn>

----- Original Message -----
From: "Ju Jiubin" <jjb@mail.jlu.edu.cn>
To: <wsffly@sohu.com>
Cc: "Li Qiang" <sckextjg@mail.jlu.edu.cn>
Sent: Thursday, April 01, 2004 1:35 PM
Subject: Re: 对理论根据的完善

> 可以了。题目叫什么？还有摘要、英文摘要等，按硕士论文要求补全。
> 可以在此基础上写篇文章，要按照科研项目要求，与李强共同完成。
> ----- Original Message -----
> From: <wsffly@sohu.com>
> To: <jjb@mail.jlu.edu.cn>
> Sent: Wednesday, March 31, 2004 3:47 PM
> Subject: 对理论根据的完善
>
>
> >   鞠老师：
> >   您好!
> >   针对理论根据问题，李强师兄帮忙对
> > 1.2 相关工作研究现状
> > 3.2 原理及依据
> > 6.1 同类工作比较
> > 进行了修改。另外添加
> > 4.4 上下游关系。
> >   请老师过目。
> >   祝老师身体健康！
> >
> > --学生：王少甫
> > 2004-3-31
> >
> > >     还是老问题：你的‘基于变化率的连接链反向追踪’方法是在他人的什么工作基础上提出来的，应该给出引用文献并且加以说明。总不能是凭空想出来的吧？这就是理论根据。所以在有关的章节中应该给出说明和相关文献，特别是‘相关工作’一节，以及在‘基于变化率的连接链反向追踪模型’一章。
> >
 
 
 

Make FREE PC-to-PC calls with MSN Messenger. Get it now! From wsffree@hotmail.com Thu Sep 15 16:45:43 2005 From: wsffree@hotmail.com (Shaofu Wang) Date: Thu, 15 Sep 2005 15:45:43 +0000 Subject: [Bro] Please help me take back password of wsffly@sohu.com Message-ID:
Hi All
 
 
     After many failure, I must turn to you to help me take back
password of wsffly@sohu.com
 
pop3: pop3.sohu.com
stmp: stmp.sohu.com
 
   I promise the email is mine. Following is some mail in wsffly@sohu.com
 
    Please Please Please do help me.
   Looking forward your return.
 
Have a nice day!
--Shaofu Wang
 
 
+++++++++++++++++++++
subject:   RE: your job application
time:      2005-1-26 13:32:59
from:     Joerg Winkler<jw1@ttpcom.com>

Hi Shaofu Wang,
I will call you at 12.00pm (noon) this Friday for about
half an hour.
Best regards,
Joerg Winkler
> -----Original Message-----
> From: wsffly@sohu.com [mailto:wsffly@sohu.com]
> Sent: Tuesday, January 25, 2005 8:18 PM
> To: jw1@ttpcom.com
> Subject: Re:your job application
>
>
>  Hi Joerg Winkler,
>
>      Thank you so much for the chance, you give me!
>
>      I accept your suggestion. My lunch break time (every day) and
>
> Friday evening, is available. Just call me at your appropriate time.
>
> And my number is 0011-86-13688859080 (It is CMCC number,13688859080).
>
>
> Best regards,
>
> sincerely.
>
> --Shaofu Wang
>
>
>
> >
> >
> >
> > I would like to have a phone interview with you to discuss your
> > opportunities
> >
> > in TTPCOM. Since you apply from a customer I would like that you are not
> >
> > within Soutec during the interview. I therefore suggest that we have the
> >
> > interview preferably during your lunch break or in the evening this
> week.
> >
> > At lunch time I am available the whole week, in the evenings only on
> > Thursday
> >
> > or Friday. Please let me know when it suites you and the phone number
> >
> > I should call you on.
> >
> >
> >
> > Best regards,
> >
> > Joerg Winkler
> >
> >
> >
> > TTPCOM Singapore
> >
> > Tel +65 62265250 (office)
> >
>
 

 
 
+++++++++++++++++++++
(Read In Chinese , Please)
 
subject:  Fw: 对理论根据的完善
time:     2004-4-2 16:01:42
from:    Ju Jiubin<jjb@mail.jlu.edu.cn>

----- Original Message -----
From: "Ju Jiubin" <jjb@mail.jlu.edu.cn>
To: <wsffly@sohu.com>
Cc: "Li Qiang" <sckextjg@mail.jlu.edu.cn>
Sent: Thursday, April 01, 2004 1:35 PM
Subject: Re: 对理论根据的完善

> 可以了。题目叫什么？还有摘要、英文摘要等，按硕士论文要求补全。
> 可以在此基础上写篇文章，要按照科研项目要求，与李强共同完成。
> ----- Original Message -----
> From: <wsffly@sohu.com>
> To: <jjb@mail.jlu.edu.cn>
> Sent: Wednesday, March 31, 2004 3:47 PM
> Subject: 对理论根据的完善
>
>
> >   鞠老师：
> >   您好!
> >   针对理论根据问题，李强师兄帮忙对
> > 1.2 相关工作研究现状
> > 3.2 原理及依据
> > 6.1 同类工作比较
> > 进行了修改。另外添加
> > 4.4 上下游关系。
> >   请老师过目。
> >   祝老师身体健康！
> >
> > --学生：王少甫
> > 2004-3-31
> >
> > >     还是老问题：你的‘基于变化率的连接链反向追踪’方法是在他人的什么工作基础上提出来的，应该给出引用文献并且加以说明。总不能是凭空想出来的吧？这就是理论根据。所以在有关的章节中应该给出说明和相关文献，特别是‘相关工作’一节，以及在‘基于变化率的连接链反向追踪模型’一章。
> >
 
 
 

Make FREE PC-to-PC calls with MSN Messenger. Get it now! From gklok@cogeco.ca Mon Sep 19 05:39:56 2005 From: gklok@cogeco.ca (Gordon Willem Klok) Date: Mon, 19 Sep 2005 00:39:56 -0400 Subject: [Bro] Patches necessary to build Bro 0.9a9 on OpenBSD 3.8 Message-ID: <432E411C.70601@cogeco.ca> Hello the following changes were necessary to build Bro on OpenBSD 3.8. aux/pcap-0.7.2 --- nametoaddr.c.orig Tue Sep 13 03:18:47 2005 +++ nametoaddr.c Tue Sep 13 03:20:55 2005 @@ -364,7 +364,7 @@ * "const char *", so no matter how we declare it here, it'll fail to * compile on one of 3.x or 4.x). */ -#if !defined(sgi) && !defined(__NetBSD__) && !defined(__FreeBSD__) +#if !defined(sgi) && !defined(__NetBSD__) && !defined(__FreeBSD__) && !defined(__OpenBSD__) extern int ether_hostton(char *, struct ether_addr *); #endif aux/hf slight change leaves the check for NEED_NAMESER_COMPAT_H however ensures that NS_MAXDNAME, NS_INADDRSIZ and NS_IN6ADDRSZ are defined (as OpenBSD lacks and the above are not defined in . --- hf.l.orig Tue Sep 13 03:31:25 2005 +++ hf.l Mon Sep 19 00:37:44 2005 @@ -16,17 +16,17 @@ #ifdef NEED_NAMESER_COMPAT_H #include - #ifndef NS_MAXDNAME - #define NS_MAXDNAME 1025 - #endif - #ifndef NS_INADDRSZ - #define NS_INADDRSZ 4 - #endif - #ifndef NS_IN6ADDRSZ - #define NS_IN6ADDRSZ 16 - #endif #else #include + #endif + #ifndef NS_MAXDNAME + #define NS_MAXDNAME 1025 + #endif + #ifndef NS_INADDRSZ + #define NS_INADDRSZ 4 + #endif + #ifndef NS_IN6ADDRSZ + #define NS_IN6ADDRSZ 16 #endif #include Hope this is helpful, GWK From jruggieri@ucdavis.edu Mon Sep 19 22:56:05 2005 From: jruggieri@ucdavis.edu (Joncarlo Ruggieri) Date: Mon, 19 Sep 2005 14:56:05 -0700 (PDT) Subject: [Bro] Removing tags from traffic Message-ID: Hi, Our Network Operations Center made some changes to the infrastructure, and now all traffic seen by our Bro systems is tagged. As a result, Bro is not capturing traffic (or so it seems). Is it possible to configure Bro to remove or ignore the tags? Are there any (other) suggestions? We are also checking with our NOC to see if they can un-tag the traffic. Thanks! Jon Ruggieri University of CA, Davis Data Center & Client Services From a.greenhalgh@cs.ucl.ac.uk Mon Sep 19 23:09:05 2005 From: a.greenhalgh@cs.ucl.ac.uk (Adam Greenhalgh) Date: Mon, 19 Sep 2005 23:09:05 +0100 Subject: [Bro] Removing tags from traffic In-Reply-To: References: Message-ID: <4769af410509191509608c6f7d@mail.gmail.com> # Make any changes to policy starting here @load vlan try adding that to .bro in /usr/local/bro/site adam On 19/09/05, Joncarlo Ruggieri wrote: > Hi, > > Our Network Operations Center made some changes to the infrastructure, and > now all traffic seen by our Bro systems is tagged. As a result, Bro is > not capturing traffic (or so it seems). Is it possible to configure Bro > to remove or ignore the tags? Are there any (other) suggestions? > > We are also checking with our NOC to see if they can un-tag the traffic. > > Thanks! > > Jon Ruggieri > University of CA, Davis > Data Center & Client Services > > _______________________________________________ > Bro mailing list > bro@bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > From scampbell@lbl.gov Mon Sep 19 23:18:51 2005 From: scampbell@lbl.gov (scott campbell) Date: Mon, 19 Sep 2005 15:18:51 -0700 Subject: [Bro] Removing tags from traffic In-Reply-To: References: Message-ID: <432F394B.1070805@lbl.gov> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3C36C1AB98D00CF3423C3442 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Joncarlo Ruggieri wrote: > Hi, > > Our Network Operations Center made some changes to the infrastructure, and > now all traffic seen by our Bro systems is tagged. As a result, Bro is > not capturing traffic (or so it seems). Is it possible to configure Bro > to remove or ignore the tags? Are there any (other) suggestions? > > We are also checking with our NOC to see if they can un-tag the traffic. > > Thanks! > > Jon Ruggieri > University of CA, Davis > Data Center & Client Services > > _______________________________________________ > Bro mailing list > bro@bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro You are referring to vlan tagging? If so, try adding vlan.bro policy to your config and you should get better results. Note this will prevent you from seeing any non-vlan traffic. scott --------------enig3C36C1AB98D00CF3423C3442 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDLzlPK2Plq8B7ZBwRAp5gAJ9p6CEOh6E2cPLkNbtz/WqJwEj5mQCgqUQM w+QhDBcurOGideYoNPSjn+U= =qq10 -----END PGP SIGNATURE----- --------------enig3C36C1AB98D00CF3423C3442-- From jruggieri@ucdavis.edu Mon Sep 19 23:25:23 2005 From: jruggieri@ucdavis.edu (Joncarlo Ruggieri) Date: Mon, 19 Sep 2005 15:25:23 -0700 (PDT) Subject: [Bro] Bro vlan tagging Message-ID: Hi, Thanks for the quick replies! Within vlan.bro, will I need to define the vlans and their tags? I see: redef restrict_filters += { ["vlan"] = "vlan" }; Do I list a vlan name within the ["vlan"] and some tag information within the other "vlan"? Is the second part an actual tag or subnet/mask data? Thanks again! Jon Ruggieri From christian@whoop.org Tue Sep 20 00:18:07 2005 From: christian@whoop.org (Christian Kreibich) Date: Mon, 19 Sep 2005 16:18:07 -0700 Subject: [Bro] Bro vlan tagging In-Reply-To: References: Message-ID: <1127171887.10898.123.camel@localhost> On Mon, 2005-09-19 at 15:25 -0700, Joncarlo Ruggieri wrote: > Hi, > > Thanks for the quick replies! > > Within vlan.bro, will I need to define the vlans and their tags? > > I see: > > redef restrict_filters += { ["vlan"] = "vlan" }; > > Do I list a vlan name within the ["vlan"] and some tag information within > the other "vlan"? Is the second part an actual tag or subnet/mask data? Have a look at pcap.bro, where restrict_filters is defined. The former "vlan" is just a textual identifier, the second is the actual addition to the pcap filtering expression that will narrow the filtering down further -- it effectively comes down to filtering "vlan and (remaining filter)". What Adam and Scott meant was to just @load vlan.bro into your configuration, not change anything inside vlan.bro. If you need to filter on a specific tag, I believe pcap.bro will need some tweaking. Let us know if that's the case (or everyone please do correct me if I'm wrong). Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From vern@icir.org Tue Sep 20 01:12:47 2005 From: vern@icir.org (Vern Paxson) Date: Mon, 19 Sep 2005 17:12:47 -0700 Subject: [Bro] Bro vlan tagging In-Reply-To: Your message of Mon, 19 Sep 2005 16:18:07 PDT. Message-ID: <200509200012.j8K0Cl0o014926@jaguar.icir.org> > If you need to filter on a specific tag, I believe pcap.bro will need > some tweaking. For a VLAN with tag XX, I think the following might work (in place of loading vlan.bro): redef restrict_filters += { ["vlan"] = "vlan XX" }; redef encap_hdr_size = 4; or for a set of VLAN's with tags XX, YY and ZZ: redef restrict_filters += { ["vlan"] = "vlan XX or vlan YY or vlan ZZ" }; redef encap_hdr_size = 4; - Vern From jruggieri@ucdavis.edu Tue Sep 20 01:52:31 2005 From: jruggieri@ucdavis.edu (Joncarlo Ruggieri) Date: Mon, 19 Sep 2005 17:52:31 -0700 (PDT) Subject: [Bro] Bro vlan tagging Message-ID: Hi, Thanks again for the clarifications. I don't think I need to specify VLANs. I will try loading vlan.bro without making changes to it. Again, I appreciate the support! Jon Ruggieri UC Davis From bchen@cs.ucf.edu Wed Sep 21 02:47:16 2005 From: bchen@cs.ucf.edu (bchen@cs.ucf.edu) Date: Tue, 20 Sep 2005 21:47:16 -0400 Subject: [Bro] for loop In-Reply-To: <200509201901.j8KJ1JBA005106@fruitcake.ICSI.Berkeley.EDU> References: <200509201901.j8KJ1JBA005106@fruitcake.ICSI.Berkeley.EDU> Message-ID: <20050920214716.yf3med3c0g88ssow@mail.cs.ucf.edu> Hello everyone, Doese anyone know how to implement for loop statement similar with the following C code: for(i=0;i<10;i++){ } thanks Bing From bchen@cs.ucf.edu Wed Sep 21 04:39:34 2005 From: bchen@cs.ucf.edu (bchen@cs.ucf.edu) Date: Tue, 20 Sep 2005 23:39:34 -0400 Subject: [Bro] ssl analyzer In-Reply-To: <200509201901.j8KJ1JBA005106@fruitcake.ICSI.Berkeley.EDU> References: <200509201901.j8KJ1JBA005106@fruitcake.ICSI.Berkeley.EDU> Message-ID: <20050920233934.dvi4spgfq8kgsocw@mail.cs.ucf.edu> Hi all, I am using Redhat Linux 7.3 with SSL v2 (has known vulnerability) to do some experiments. I use Mozilla Firefox to access the https service in Linux 7.3 that has a self-signed certificate. I let Bro monitor this access. The following log is in Weird log file. 1127272310.138988 ** 192.168.1.2/47011 > 172.16.112.5/https: SSLv2: FATAL: recordLength doesn't match data block length! 1127272315.420757 ** 192.168.1.2/47012 > 172.16.112.5/https: SSLv2: FATAL: recordLength doesn't match data block length! And the ssl.log is empty. Two questions: (1)What are these two log entries about? (2)I found no event in the ssl analyzer was fired. I put a single print command in each event handler in the ssl analyzer, and no single event handler was called. Why can this happen? Please be noted that I already load ssl in mt.bro and I run bro like this "./bro -i eth1 mt". Any suggestion or comment? thanks for your time Bing From scampbell@lbl.gov Wed Sep 21 18:13:07 2005 From: scampbell@lbl.gov (scott campbell) Date: Wed, 21 Sep 2005 10:13:07 -0700 Subject: [Bro] for loop In-Reply-To: <20050921121829.11j18m2o00sk80ok@mail.cs.ucf.edu> References: <200509201901.j8KJ1JBA005106@fruitcake.ICSI.Berkeley.EDU> <20050920214716.yf3med3c0g88ssow@mail.cs.ucf.edu> <433108B0.8050308@lbl.gov> <20050921121829.11j18m2o00sk80ok@mail.cs.ucf.edu> Message-ID: <433194A3.8020508@lbl.gov> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF93C4A6257B0B2C20965DCCE Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit bchen@cs.ucf.edu wrote: > Thanks Scott. This is a good suggestion. but what if the upper bound (10 > in my > example) is a variable? The corresponding c code is like this: > > for(i=0;i > I also want to the for loop executes from 0 to max in increasing order. > How to > do that? > > thanks > > Bing > > > Quoting scott campbell : > >> bchen@cs.ucf.edu wrote: >> >>> Hello everyone, >>> Doese anyone know how to implement for loop statement similar >>> with the >>> following C code: >>> >>> for(i=0;i<10;i++){ >>> } >>> >>> thanks >>> >>> Bing >>> >>> >>> _______________________________________________ >>> Bro mailing list >>> bro@bro-ids.org >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro >> >> >> I had to do this once and did something like: >> >> const LIST = { 1,2,3,4,5,6 }; >> local i: count; >> >> for ( i in LIST ) >> { >> >> } >> >> I can look for the code in the morning (as the LIST defn is probably >> not correct), and perhaps someone may come up with something less vile. >> >> scott >> >> > > I dont think that that functionality is supported. The CHANGES file is typically the best documentation for new/added functionality. In this case, there are two references to what you are looking for: The original: > - There's now a "for" statement to iterate over the indices of a table > or the members of a set: > > for ( i in foo ) > > for the above "foo" will iterate with i assigned to 1, 2, and 3; *but > not in general in that order*. > and later: > - Iterating over multi-dimensional tables/sets now works (Robin Sommer). > For example: > > const remote_peers_ssl : table[addr, port] of Peer &redef; > [...] > for ( [ip, p] in remote_peers_ssl ) > connect_ssl(ip, p, remote_peers_ssl[ip, p]$retry); This is not the first time that this has come up, but generic looping has been discouraged in general for performance reasons. On the other hand if you want to add something... :-) scott --------------enigF93C4A6257B0B2C20965DCCE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDMZSnK2Plq8B7ZBwRAioqAJ9ipuMncm0F9y4ejk/1BFOlkf3W9QCgraeK rGsEwAhw1uxeJ+LMc9pJ+Bk= =PsE6 -----END PGP SIGNATURE----- --------------enigF93C4A6257B0B2C20965DCCE-- From vern@icir.org Wed Sep 21 18:23:51 2005 From: vern@icir.org (Vern Paxson) Date: Wed, 21 Sep 2005 10:23:51 -0700 Subject: [Bro] for loop In-Reply-To: Your message of Wed, 21 Sep 2005 10:13:07 PDT. Message-ID: <200509211723.j8LHNpBC019116@jaguar.icir.org> > This is not the first time that this has come up, but generic looping > has been discouraged in general for performance reasons. Now not so much for performance reasons (though that was the original reason) but to push on users to think about using other language constructs that achieve the same results using more abstracted data structures. The notion is that often there's a way to express what you want to do using sets, tables, or events. Vern From scampbell@lbl.gov Wed Sep 21 18:53:41 2005 From: scampbell@lbl.gov (scott campbell) Date: Wed, 21 Sep 2005 10:53:41 -0700 Subject: [Bro] ssl analyzer In-Reply-To: <20050920233934.dvi4spgfq8kgsocw@mail.cs.ucf.edu> References: <200509201901.j8KJ1JBA005106@fruitcake.ICSI.Berkeley.EDU> <20050920233934.dvi4spgfq8kgsocw@mail.cs.ucf.edu> Message-ID: <43319E25.8010000@lbl.gov> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig45932E9C44E05E4D463A1B78 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit bchen@cs.ucf.edu wrote: > Hi all, > I am using Redhat Linux 7.3 with SSL v2 (has known vulnerability) to > do some > experiments. I use Mozilla Firefox to access the https service in Linux 7.3 > that has a self-signed certificate. I let Bro monitor this access. The > following log is in Weird log file. > > 1127272310.138988 ** 192.168.1.2/47011 > 172.16.112.5/https: SSLv2: FATAL: > recordLength doesn't match data block length! > 1127272315.420757 ** 192.168.1.2/47012 > 172.16.112.5/https: SSLv2: FATAL: > recordLength doesn't match data block length! > > And the ssl.log is empty. > > Two questions: > (1)What are these two log entries about? > (2)I found no event in the ssl analyzer was fired. I put a single print > command > in each event handler in the ssl analyzer, and no single event handler was > called. Why can this happen? Please be noted that I already load ssl in > mt.bro > and I run bro like this "./bro -i eth1 mt". > > Any suggestion or comment? > > thanks for your time > > > Bing > > > > > _______________________________________________ > Bro mailing list > bro@bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro The two errors are from the event generation side of bro in SSLv2.cc, in the section where the record header is being analyzed. The analysis probably does not even get to the policy side, so adding further print statements will not get you anywhere. Look at SSLv2_Interpreter::NewSSLRecord() , there is a consistency test being done between the length of the header record and the value that the header record claims. Probably around line 154 or 170. If you have a trace of this transaction, I would be happy to run it and see if there is a problem with the analyzer. thanks! scott --------------enig45932E9C44E05E4D463A1B78 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDMZ4lK2Plq8B7ZBwRAiqVAKDM1oDKpksH8yTvkBpEWJkfb7erfACeI5rC ORv2LD2bPY1wqgWbsPk1ffY= =Qy2i -----END PGP SIGNATURE----- --------------enig45932E9C44E05E4D463A1B78-- From vern@icir.org Wed Sep 21 21:36:00 2005 From: vern@icir.org (Vern Paxson) Date: Wed, 21 Sep 2005 13:36:00 -0700 Subject: [Bro] Patches necessary to build Bro 0.9a9 on OpenBSD 3.8 In-Reply-To: Your message of Mon, 19 Sep 2005 00:39:56 EDT. Message-ID: <200509212036.j8LKa0fl024210@jaguar.icir.org> > Hello the following changes were necessary to build Bro on OpenBSD 3.8. Please give this a try with 0.9a10 (the latest CURRENT), configuring with ./configure --disable-localpcap. It looks like the change for hf.l is already integrated. Vern From vern@icir.org Wed Sep 21 21:36:51 2005 From: vern@icir.org (Vern Paxson) Date: Wed, 21 Sep 2005 13:36:51 -0700 Subject: [Bro] new Bro CURRENT release (0.9a10) In-Reply-To: Your message of Tue, 13 Sep 2005 09:43:00 +0200. Message-ID: <200509212036.j8LKap5n024338@jaguar.icir.org> > I'm glad to here that new version is out, but > can someone add this to the cvs-repository? This wasn't added because it's not in fact the correct fix but just a workaround. There's logic in Bro's signal handling intended to avoid the reentrancy problem in the first place. Could you please reproduce the problem with 0.9a10 and send me (off-list) a full traceback so I can try to see where that logic is failing? > Do you plan to make cvs-repository available for anyone > (read-only of course ;-)? Probably not any time soon, unless folks want to argue that it would really be helpful. > Or at least do you plan to > make something like hot-fix-patches for last released version? It seems it's indeed time to start doing this. Related to this, I'm making 0.9a10 the basis for a continuing bug-fix-only 0.9 branch. For development, we've switched internally to 1.0 (which already has a lot of changes - stay tuned). Vern From vern@icir.org Wed Sep 21 21:36:48 2005 From: vern@icir.org (Vern Paxson) Date: Wed, 21 Sep 2005 13:36:48 -0700 Subject: [Bro] Bug on PktSrc.cc In-Reply-To: Your message of Wed, 14 Sep 2005 20:43:48 PDT. Message-ID: <200509212036.j8LKan1r024330@jaguar.icir.org> > I enclose a patch for Bro to die with a better error message. Thanks, I've integrated this. Vern From rpang@cs.princeton.edu Thu Sep 22 02:46:34 2005 From: rpang@cs.princeton.edu (Ruoming Pang) Date: Wed, 21 Sep 2005 21:46:34 -0400 Subject: [Bro] for loop In-Reply-To: <200509211723.j8LHNpBC019116@jaguar.icir.org> References: <200509211723.j8LHNpBC019116@jaguar.icir.org> Message-ID: <48ac059bc68049820008536d9c90fb1d@cs.princeton.edu> >> This is not the first time that this has come up, but generic looping >> has been discouraged in general for performance reasons. > > Now not so much for performance reasons (though that was the original > reason) but to push on users to think about using other language > constructs > that achieve the same results using more abstracted data structures. > The notion is that often there's a way to express what you want to > do using sets, tables, or events. Or using recursions, if one is desperate enough. :-) By the way, Bing, if you want to access elements in order, "vector" might be what you want. Ruoming From =?GB2312?B?0Ozgeg==?= Thu Sep 22 07:16:31 2005 From: =?GB2312?B?0Ozgeg==?= (=?GB2312?B?0Ozgeg==?=) Date: Thu, 22 Sep 2005 14:16:31 +0800 Subject: [Bro] question about bro's performance Message-ID: <68d4b8ba05092123162ab04dc6@mail.gmail.com> hello : firstly, I am sorry for my english :) . I have some questions on bro: 1. I see the introduction in bro overview: Bro targets high-speed (Gbps). I am surprised and doubt it. bro captures packets through libpcap and BPF filter,but libpcap isn't high performance. that's the reason why zero copying and DMA tech are used in IDS field. bro analyses events by policy scripts.there is a problem that script's performance is lower than binary programs.I didn't test bro's performance , maybe I am wrong. 2. I konw bro supports to define signature in regular expression.I want to konw how does bro support regular expressions: by perl or do it yourself. 3. Is there realtime alarm function in bro? I sometimes want to see the current network status on screen,instead of viewing bro's report file. many many thinks From vern@icir.org Fri Sep 23 08:09:30 2005 From: vern@icir.org (Vern Paxson) Date: Fri, 23 Sep 2005 00:09:30 -0700 Subject: [Bro] question about bro's performance In-Reply-To: Your message of Thu, 22 Sep 2005 14:16:31 +0800. Message-ID: <200509230709.j8N79UTk018459@jaguar.icir.org> > 1. I see the introduction in bro overview: Bro targets high-speed > (Gbps). I am surprised and doubt it. These issues are discussed at length in the original Bro paper and also H. Dreger, A. Feldmann, V. Paxson, and R. Sommer, Operational Experiences with High-Volume Network Intrusion Detection, Proc. ACM CCS, October 2004. available at http://www.bro-ids.org/publications.html. > 2. I konw bro supports to define signature in regular expression.I > want to konw how does bro support > regular expressions: by perl or do it yourself. It has its own implementation, which is essentially the same as the one used by the "flex" utility (freeware replacement for lex, which I wrote a long time ago). > 3. Is there realtime alarm function in bro? Yes. This is a basic question that is also answered in the Bro paper, as well as in the documentation available from bro-ids.org. Vern From nuno_romano@yahoo.com Mon Sep 26 01:00:04 2005 From: nuno_romano@yahoo.com (nuno romano) Date: Sun, 25 Sep 2005 17:00:04 -0700 (PDT) Subject: [Bro] Bro Binary(22Mb),configure run output Message-ID: <20050926000004.62652.qmail@web51305.mail.yahoo.com> I got a bro0.9 binary of 22Mb in Debian 3.1 PPC with a straightforward ./configure make.At first sight it seems a working binary.It responds to bro -v and bro -h.I did not try any further command.Below is the output of the configure run. checking build system type... powerpc-unknown-linux-gnu checking host system type... powerpc-unknown-linux-gnu checking target system type... powerpc-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets ${MAKE}... yes checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking dependency style of gcc... gcc3 checking for flex... flex checking for flex... (cached) flex checking for yywrap in -lfl... yes checking lex output file root... lex.yy checking whether yytext is a pointer... yes checking for bison... bison -y checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking for a BSD-compatible install... /usr/bin/install -c checking whether make sets ${MAKE}... (cached) yes checking for gzip... gzip checking for OPENSSL_add_all_algorithms_conf in -lcrypto... yes checking for SSL_new in -lssl... yes checking whether OPENSSL_add_all_algorithms_conf is declared... yes checking for OpenSSL >= 0.9.7... yes checking for perl5... no checking for perl... /usr/bin/perl checking for chown... /bin/chown checking Linux kernel version... 2 checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking return type of signal handlers... void checking for sigset... yes checking for int32_t using gcc... yes checking for u_int32_t using gcc... yes checking for u_int16_t using gcc... yes checking for u_int8_t using gcc... yes checking whether time.h and sys/time.h may both be included... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for memory.h... (cached) yes checking netinet/in.h usability... yes checking netinet/in.h presence... yes checking for netinet/in.h... yes checking socket.h usability... no checking socket.h presence... no checking for socket.h... no checking for netinet/ip6.h... yes checking for socklen_t... yes checking if syslog returns int... no checking if we should declare socket and friends... no checking for working memcmp... yes checking for strftime... yes checking for strerror... yes checking for strsep... yes checking for mallinfo... yes checking for library containing inet_aton... none required checking for ns_initparse in -lresolv... no checking for ns_initparse in resolver... yes checking for tgetnum in -ltermcap... yes checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes checking whether byte ordering is bigendian... yes checking for ns_msg... yes checking for res_mkquery... no checking for res_mkquery in -lresolv... yes checking for union semun... no checking for struct sembuf... yes checking for struct sockaddr_in.sin_len... no checking for long long... yes checking size of long long... 8 Using shipped pcap configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating doc/Makefile config.status: creating doc/ref-manual/Makefile config.status: creating doc/quick-start/Makefile config.status: creating doc/user-manual/Makefile config.status: creating aux/adtrace/Makefile config.status: creating aux/cf/Makefile config.status: creating aux/hf/Makefile config.status: creating aux/scripts/Makefile config.status: creating aux/bdcat/Makefile config.status: creating aux/rst/Makefile config.status: creating aux/Makefile config.status: creating policy/Makefile config.status: creating policy/sigs/Makefile config.status: creating scripts/Makefile config.status: creating scripts/bro_config config.status: creating scripts/bro.rc config.status: creating scripts/localnetMAC.pl config.status: creating scripts/s2b/Makefile config.status: creating scripts/s2b/bro-include/Makefile config.status: creating scripts/s2b/example_bro_files/Makefile config.status: creating scripts/s2b/etc/Makefile config.status: creating scripts/s2b/bin/Makefile config.status: creating scripts/s2b/pm/Makefile config.status: creating scripts/s2b/snort_rules2.2//Makefile config.status: creating config.h config.status: executing default-1 commands config.status: executing default commands Using install prefix /usr/local/bro Compiling Bro with OpenSSL support: Yes Using perl /usr/bin/perl Using non-blocking main loop: No __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From billowhe_2000@163.com Mon Sep 26 14:01:06 2005 From: billowhe_2000@163.com (He Haitao) Date: Mon, 26 Sep 2005 21:01:06 +0800 Subject: [Bro] About Bro and splitting of the tcpdump trace Message-ID: <200509261302.j8QD2JBA019142@fruitcake.ICSI.Berkeley.EDU> Hi, I want to find a tool to split the captured trace (using tcpdump tool) into two parts: the normal sub-trace and the abnormal one which compising of network attacks detected, can the Bro do ? If not, any suggestion is perferred. Thanks a lot! Yours, He From rpang@cs.princeton.edu Mon Sep 26 15:34:03 2005 From: rpang@cs.princeton.edu (Ruoming Pang) Date: Mon, 26 Sep 2005 10:34:03 -0400 Subject: [Bro] Bro Binary(22Mb),configure run output In-Reply-To: <20050926000004.62652.qmail@web51305.mail.yahoo.com> References: <20050926000004.62652.qmail@web51305.mail.yahoo.com> Message-ID: <421a2a4b3ce23411c3b2e254e7350498@cs.princeton.edu> Thanks, nuno. Would you please also do a 'ls -l src/*.o' to list the size of object files? Thanks! Ruoming On Sep 25, 2005, at 8:00 PM, nuno romano wrote: > I got a bro0.9 binary of 22Mb in Debian 3.1 PPC > with a straightforward ./configure make.At > first sight it seems a working binary.It > responds to bro -v and bro -h.I did not try > any further command.Below is the output > of the configure run. > > checking build system type... > powerpc-unknown-linux-gnu > checking host system type... powerpc-unknown-linux-gnu > checking target system type... > powerpc-unknown-linux-gnu > checking for a BSD-compatible install... > /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets ${MAKE}... yes > checking for style of include used by make... GNU > checking for gcc... gcc > checking for C compiler default output... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... > yes > checking whether gcc accepts -g... yes > checking dependency style of gcc... gcc3 > checking for flex... flex > checking for flex... (cached) flex > checking for yywrap in -lfl... yes > checking lex output file root... lex.yy > checking whether yytext is a pointer... yes > checking for bison... bison -y > checking for g++... g++ > checking whether we are using the GNU C++ compiler... > yes > checking whether g++ accepts -g... yes > checking dependency style of g++... gcc3 > checking for a BSD-compatible install... > /usr/bin/install -c > checking whether make sets ${MAKE}... (cached) yes > checking for gzip... gzip > checking for OPENSSL_add_all_algorithms_conf in > -lcrypto... yes > checking for SSL_new in -lssl... yes > checking whether OPENSSL_add_all_algorithms_conf is > declared... yes > checking for OpenSSL >= 0.9.7... yes > checking for perl5... no > checking for perl... /usr/bin/perl > checking for chown... /bin/chown > checking Linux kernel version... 2 > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking return type of signal handlers... void > checking for sigset... yes > checking for int32_t using gcc... yes > checking for u_int32_t using gcc... yes > checking for u_int16_t using gcc... yes > checking for u_int8_t using gcc... yes > checking whether time.h and sys/time.h may both be > included... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking for memory.h... (cached) yes > checking netinet/in.h usability... yes > checking netinet/in.h presence... yes > checking for netinet/in.h... yes > checking socket.h usability... no > checking socket.h presence... no > checking for socket.h... no > checking for netinet/ip6.h... yes > checking for socklen_t... yes > checking if syslog returns int... no > checking if we should declare socket and friends... no > checking for working memcmp... yes > checking for strftime... yes > checking for strerror... yes > checking for strsep... yes > checking for mallinfo... yes > checking for library containing inet_aton... none > required > checking for ns_initparse in -lresolv... no > checking for ns_initparse in resolver... yes > checking for tgetnum in -ltermcap... yes > checking readline/readline.h usability... yes > checking readline/readline.h presence... yes > checking for readline/readline.h... yes > checking whether byte ordering is bigendian... yes > checking for ns_msg... yes > checking for res_mkquery... no > checking for res_mkquery in -lresolv... yes > checking for union semun... no > checking for struct sembuf... yes > checking for struct sockaddr_in.sin_len... no > checking for long long... yes > checking size of long long... 8 > Using shipped pcap > configure: creating ./config.status > config.status: creating Makefile > config.status: creating src/Makefile > config.status: creating doc/Makefile > config.status: creating doc/ref-manual/Makefile > config.status: creating doc/quick-start/Makefile > config.status: creating doc/user-manual/Makefile > config.status: creating aux/adtrace/Makefile > config.status: creating aux/cf/Makefile > config.status: creating aux/hf/Makefile > config.status: creating aux/scripts/Makefile > config.status: creating aux/bdcat/Makefile > config.status: creating aux/rst/Makefile > config.status: creating aux/Makefile > config.status: creating policy/Makefile > config.status: creating policy/sigs/Makefile > config.status: creating scripts/Makefile > config.status: creating scripts/bro_config > config.status: creating scripts/bro.rc > config.status: creating scripts/localnetMAC.pl > config.status: creating scripts/s2b/Makefile > config.status: creating > scripts/s2b/bro-include/Makefile > config.status: creating > scripts/s2b/example_bro_files/Makefile > config.status: creating scripts/s2b/etc/Makefile > config.status: creating scripts/s2b/bin/Makefile > config.status: creating scripts/s2b/pm/Makefile > config.status: creating > scripts/s2b/snort_rules2.2//Makefile > config.status: creating config.h > config.status: executing default-1 commands > config.status: executing default commands > > Using install prefix /usr/local/bro > Compiling Bro with OpenSSL support: Yes > Using perl /usr/bin/perl > Using non-blocking main loop: No > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > _______________________________________________ > Bro mailing list > bro@bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From rpang@cs.princeton.edu Mon Sep 26 18:04:59 2005 From: rpang@cs.princeton.edu (Ruoming Pang) Date: Mon, 26 Sep 2005 13:04:59 -0400 Subject: [Bro] About Bro and splitting of the tcpdump trace In-Reply-To: <200509261302.j8QD2JBA019142@fruitcake.ICSI.Berkeley.EDU> References: <200509261302.j8QD2JBA019142@fruitcake.ICSI.Berkeley.EDU> Message-ID: <7ffacd2cfbcebcce52d24b649f7806c7@cs.princeton.edu> > I want to find a tool to split the captured trace (using tcpdump tool) > into two parts: the normal sub-trace and the abnormal one which > compising of network attacks detected, can the Bro do ? If not, any > suggestion is perferred. I can answer part of the question. Suppose you want to split a trace into two sets of connections, A and B. If you can write a Bro policy script to determine for each connection whether it belongs to A or B, you can instruct Bro to write packets to an output trace on connection-by-connection basis. The function to call is: # Dump original packets on the connection up to this point to the # output trace, if any. function dump_packets_of_connection%(c: connection%): any Ruoming From nuno_romano@yahoo.com Wed Sep 28 01:32:06 2005 From: nuno_romano@yahoo.com (nuno romano) Date: Tue, 27 Sep 2005 17:32:06 -0700 (PDT) Subject: [Bro] Bro0.9Binary(22Mb)-Continued Message-ID: <20050928003207.30577.qmail@web51315.mail.yahoo.com> 185096 2005-09-27 15:17 bro-0.9a9/src/Active.o 535720 2005-09-27 15:18 bro-0.9a9/src/Anon.o 437748 2005-09-27 15:18 bro-0.9a9/src/Attr.o 572236 2005-09-27 15:18 bro-0.9a9/src/BackDoor.o 510424 2005-09-27 15:18 bro-0.9a9/src/Base64.o 18936 2005-09-27 15:14 bro-0.9a9/src/bif_arg.o 53240 2005-09-27 15:14 bro-0.9a9/src/bif_lex.o 118052 2005-09-27 15:14 bro-0.9a9/src/bif_parse.o 31104 2005-09-27 15:18 bro-0.9a9/src/BPF_Program.o 100564 2005-09-27 15:18 bro-0.9a9/src/BroString.o 112744 2005-09-27 15:18 bro-0.9a9/src/CCL.o 389612 2005-09-27 15:19 bro-0.9a9/src/ChunkedIO.o 209448 2005-09-27 15:19 bro-0.9a9/src/CompHash.o 560240 2005-09-27 15:19 bro-0.9a9/src/ConnCompressor.o 616356 2005-09-27 15:19 bro-0.9a9/src/Conn.o 23896 2005-09-27 15:43 bro-0.9a9/src/cq.o 321312 2005-09-27 15:21 bro-0.9a9/src/DbgBreakpoint.o 254632 2005-09-27 15:21 bro-0.9a9/src/DbgHelp.o 257400 2005-09-27 15:21 bro-0.9a9/src/DbgWatch.o 530768 2005-09-27 15:20 bro-0.9a9/src/DCE_RPC.o 562916 2005-09-27 15:22 bro-0.9a9/src/DebugCmds.o 900 2005-09-27 15:22 bro-0.9a9/src/DebugLogger.o 462172 2005-09-27 15:21 bro-0.9a9/src/Debug.o 149524 2005-09-27 15:22 bro-0.9a9/src/Desc.o 161648 2005-09-27 15:20 bro-0.9a9/src/DFA.o 97140 2005-09-27 15:22 bro-0.9a9/src/Dict.o 464444 2005-09-27 15:22 bro-0.9a9/src/Discard.o 519304 2005-09-27 15:20 bro-0.9a9/src/DNS_Mgr.o 601924 2005-09-27 15:20 bro-0.9a9/src/DNS.o 38236 2005-09-27 15:22 bro-0.9a9/src/EquivClass.o 445972 2005-09-27 15:22 bro-0.9a9/src/EventHandler.o 441308 2005-09-27 15:22 bro-0.9a9/src/Event.o 452860 2005-09-27 15:23 bro-0.9a9/src/EventRegistry.o 1105264 2005-09-27 15:24 bro-0.9a9/src/Expr.o 483528 2005-09-27 15:24 bro-0.9a9/src/File.o 656956 2005-09-27 15:24 bro-0.9a9/src/Finger.o 486592 2005-09-27 15:25 bro-0.9a9/src/Frag.o 287664 2005-09-27 15:25 bro-0.9a9/src/Frame.o 665456 2005-09-27 15:24 bro-0.9a9/src/FTP.o 1317696 2005-09-27 15:26 bro-0.9a9/src/Func.o 583116 2005-09-27 15:26 bro-0.9a9/src/Gnutella.o 67572 2005-09-27 15:27 bro-0.9a9/src/Hash.o 858788 2005-09-27 15:27 bro-0.9a9/src/HTTP.o 560364 2005-09-27 15:27 bro-0.9a9/src/ICMP.o 663000 2005-09-27 15:28 bro-0.9a9/src/Ident.o 487228 2005-09-27 15:27 bro-0.9a9/src/ID.o 544068 2005-09-27 15:28 bro-0.9a9/src/InterConn.o 15816 2005-09-27 15:28 bro-0.9a9/src/IntSet.o 84320 2005-09-27 15:28 bro-0.9a9/src/IOSource.o 34556 2005-09-27 15:28 bro-0.9a9/src/List.o 150512 2005-09-27 15:28 bro-0.9a9/src/Logger.o 552384 2005-09-27 15:28 bro-0.9a9/src/Login.o 636440 2005-09-27 15:15 bro-0.9a9/src/main.o 8648 2005-09-27 15:43 bro-0.9a9/src/md5.o 672692 2005-09-27 15:29 bro-0.9a9/src/MIME.o 50164 2005-09-27 15:43 bro-0.9a9/src/nb_dns.o 555256 2005-09-27 15:31 bro-0.9a9/src/NetbiosSSN.o 678696 2005-09-27 15:30 bro-0.9a9/src/Net.o 44380 2005-09-27 15:15 bro-0.9a9/src/net_util.o 400420 2005-09-27 15:31 bro-0.9a9/src/NetVar.o 150108 2005-09-27 15:29 bro-0.9a9/src/NFA.o 539828 2005-09-27 15:29 bro-0.9a9/src/NFS.o 528208 2005-09-27 15:29 bro-0.9a9/src/NTP.o 560008 2005-09-27 15:30 bro-0.9a9/src/NVT.o 431392 2005-09-27 15:31 bro-0.9a9/src/Obj.o 282228 2005-09-27 15:31 bro-0.9a9/src/OSFinger.o 195284 2005-09-27 15:31 bro-0.9a9/src/PacketFilter.o 572180 2005-09-27 15:32 bro-0.9a9/src/PacketSort.o 677384 2005-09-27 15:16 bro-0.9a9/src/parse.o 43892 2005-09-27 15:43 bro-0.9a9/src/patricia.o 573244 2005-09-27 15:32 bro-0.9a9/src/PersistenceSerializer.o 519740 2005-09-27 15:32 bro-0.9a9/src/PktSrc.o 343024 2005-09-27 15:32 bro-0.9a9/src/PolicyFile.o 547448 2005-09-27 15:33 bro-0.9a9/src/Portmap.o 195284 2005-09-27 15:33 bro-0.9a9/src/PrefixTable.o 32912 2005-09-27 15:33 bro-0.9a9/src/PriorityQueue.o 30744 2005-09-27 15:33 bro-0.9a9/src/Queue.o 419148 2005-09-27 15:34 bro-0.9a9/src/Reassem.o 587932 2005-09-27 15:34 bro-0.9a9/src/RemoteSerializer.o 467072 2005-09-27 15:33 bro-0.9a9/src/RE.o 129760 2005-09-27 15:17 bro-0.9a9/src/re-parse.o 139864 2005-09-27 15:17 bro-0.9a9/src/re-scan.o 528660 2005-09-27 15:34 bro-0.9a9/src/Rlogin.o 545552 2005-09-27 15:33 bro-0.9a9/src/RPC.o 531620 2005-09-27 15:34 bro-0.9a9/src/RSH.o 514356 2005-09-27 15:35 bro-0.9a9/src/RuleAction.o 531292 2005-09-27 15:35 bro-0.9a9/src/RuleCondition.o 603136 2005-09-27 15:35 bro-0.9a9/src/RuleMatcher.o 513972 2005-09-27 15:35 bro-0.9a9/src/Rule.o 534192 2005-09-27 15:17 bro-0.9a9/src/rule-parse.o 527328 2005-09-27 15:17 bro-0.9a9/src/rule-scan.o 353096 2005-09-27 15:16 bro-0.9a9/src/scan.o 234132 2005-09-27 15:37 bro-0.9a9/src/Scope.o 279680 2005-09-27 15:36 bro-0.9a9/src/ScriptAnaly.o 432560 2005-09-27 15:37 bro-0.9a9/src/SerializationFormat.o 661068 2005-09-27 15:37 bro-0.9a9/src/Serializer.o 496084 2005-09-27 15:37 bro-0.9a9/src/SerialObj.o 754244 2005-09-27 15:38 bro-0.9a9/src/Sessions.o 13504 2005-09-27 15:43 bro-0.9a9/src/setsignal.o 563256 2005-09-27 15:36 bro-0.9a9/src/SMB.o 723116 2005-09-27 15:36 bro-0.9a9/src/SMTP.o 518580 2005-09-27 15:36 bro-0.9a9/src/SSH.o 75564 2005-09-27 15:44 bro-0.9a9/src/SSLCiphers.o 559924 2005-09-27 15:44 bro-0.9a9/src/SSLInterpreter.o 561824 2005-09-27 15:44 bro-0.9a9/src/SSLProxy.o 564244 2005-09-27 15:44 bro-0.9a9/src/SSLv2.o 102900 2005-09-27 15:45 bro-0.9a9/src/SSLv3Automaton.o 598860 2005-09-27 15:45 bro-0.9a9/src/SSLv3.o 498496 2005-09-27 15:38 bro-0.9a9/src/StateAccess.o 549704 2005-09-27 15:38 bro-0.9a9/src/Stats.o 541444 2005-09-27 15:39 bro-0.9a9/src/SteppingStone.o 659508 2005-09-27 15:39 bro-0.9a9/src/Stmt.o 1886 2005-09-27 15:43 bro-0.9a9/src/strsep.o 579128 2005-09-27 15:40 bro-0.9a9/src/TCP_Contents.o 693992 2005-09-27 15:40 bro-0.9a9/src/TCP_Endpoint.o 759128 2005-09-27 15:40 bro-0.9a9/src/TCP.o 1044548 2005-09-27 15:41 bro-0.9a9/src/TCP_Rewriter.o 513536 2005-09-27 15:41 bro-0.9a9/src/Telnet.o 430248 2005-09-27 15:41 bro-0.9a9/src/Timer.o 256136 2005-09-27 15:41 bro-0.9a9/src/Traverse.o 634040 2005-09-27 15:42 bro-0.9a9/src/Type.o 528056 2005-09-27 15:42 bro-0.9a9/src/UDP.o 20572 2005-09-27 15:15 bro-0.9a9/src/util.o 888688 2005-09-27 15:43 bro-0.9a9/src/Val.o 470688 2005-09-27 15:43 bro-0.9a9/src/Var.o 1628 2005-09-27 15:43 bro-0.9a9/src/version.o 525508 2005-09-27 15:44 bro-0.9a9/src/X509.o 32240 2005-09-27 15:43 bro-0.9a9/src/XDR.o __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jmellander@lbl.gov Wed Sep 28 16:46:54 2005 From: jmellander@lbl.gov (Jim Mellander) Date: Wed, 28 Sep 2005 08:46:54 -0700 Subject: [Bro] [Fwd: Fwd: [TWiki-Announce] Security Alert: TWiki INCLUDE function allows arbitrary shell commandexecution] Message-ID: <433ABAEE.3020700@lbl.gov> I know the Bro twiki was patched recently, but it looks like another round of patching is appropriate. -------- Original Message -------- Subject: Fwd: [TWiki-Announce] Security Alert: TWiki INCLUDE function allows arbitrary shell commandexecution Date: Wed, 28 Sep 2005 07:35:36 -0700 From: Computer Incident Advisory Capability To: JMellander@lbl.gov CC: ciac@ciac.org, cppm@lbl.gov Jim, FYI, Thought I would pass this along. We may put out a bulletin, but it won't be for another four hours or so. Do you already subscribe to this list? Julie Driscoll ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Computer Incident Advisory Capability (CIAC) U. S. Department of Energy 866-901-CIAC or 925-422-8193 ciac@ciac.org ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) >X-Accept-Language: en >To: twiki-announce@lists.sourceforge.net, twiki-dev@lists.sourceforge.net >Cc: twiki-security@lists.sourceforge.net >X-Spam-Score: 1.1 (+) >X-Spam-Report: Spam Filtering performed by sourceforge.net. > See http://spamassassin.org/tag/ for more details. > Report problems to > http://sf.net/tracker/?func=add&group_id=1&atid=200001 > 1.0 FORGED_RCVD_HELO Received: contains a forged HELO > 0.0 SF_CHICKENPOX_PERIOD BODY: Text interparsed with . > 0.0 SF_CHICKENPOX_SLASH BODY: Text interparsed with / > 0.0 SF_CHICKENPOX_MINUS BODY: Text interparsed with - > 0.0 SF_CHICKENPOX_COLON BODY: Text interparsed with : > 0.0 SF_CHICKENPOX_UNDERSCORE BODY: Text interparsed with _ > 0.0 SF_CHICKENPOX_GREATERTHAN BODY: Text interparsed with > > 0.0 SF_CHICKENPOX_AT BODY: Text interparsed with @ > 0.0 SF_CHICKENPOX_APOSTROPHE BODY: Text interparsed with ' >From: twiki-announce-admin@lists.sourceforge.net >Reply-To: twiki-announce@lists.sourceforge.net >Subject: [TWiki-Announce] Security Alert: TWiki INCLUDE function allows >arbitrary shell > commandexecution >Sender: twiki-announce-admin@lists.sourceforge.net >X-BeenThere: twiki-announce@lists.sourceforge.net >X-Mailman-Version: 2.0.9-sf.net >List-Unsubscribe: >, > > >List-Id: TWiki announcement list - security update and release notices >(low volume) >List-Post: >List-Help: >List-Subscribe: , > > >List-Archive: > >Date: Tue, 27 Sep 2005 22:48:27 -0700 >X-Scanned-By: MIMEDefang 2.39 > >Dear TWiki Administrator, > >This advisory alerts you of a potential security issue with your >TWiki installation: The TWiki INCLUDE function allows arbitrary >shell command execution. The permanent place for this advisory is >http://twiki.org/cgi-bin/view/Codev/SecurityAlertExecuteCommandsWithInclude >where you can see updates and follow-ups. > >If you do not use TWiki, please ignore this e-mail. If you don't >administer your TWiki site, or started a site now administered by >someone else, please pass it to the current TWiki site administrator. > >Please see also unrelated security audit on visible lib directories, >http://twiki.org/cgi-bin/view/Codev/SecurityAuditOnVisibleLibDir > >Table of Contents: > > * Vulnerable Software Version > * Attack Vectors > * Impact > * MITRE Name for this Vulnerability > * Details > * Countermeasures > * Authors and Credits > * Hotfix > * Patch for TWiki Production Release 03-Sep-2004 > * Patch for TWiki Production Release 02-Sep-2004 > * Patch for TWiki Production Release 01-Feb-2003 > * TWiki News > > >---++ Vulnerable Software Version > > * TWikiRelease03Sep2004[2] -- TWiki20040903.zip > * TWikiRelease02Sep2004[3] -- TWiki20040902.zip > * TWikiRelease01Sep2004[4] -- TWiki20040901.zip > * TWikiRelease01Feb2003[5] -- TWiki20030201.zip > >Not affected are: > * Recent DakarReleases[6] (upcoming production release, soon) > * TWikiRelease01Sep2004 patched with Florian Weimer's > UncoordinatedSecurityAlert23Feb2005[7] > > >---++ Attack Vectors > >Editing wiki pages and HTTP GET requests towards the Wiki server >(typically port 80/TCP). Typically, prior authentication is >necessary (including anonymous TWikiGuest accounts). > > >---++ Impact > >An attacker is able to execute arbitrary shell commands with the >privileges of the web server process, such as user nobody. > > >---++ MITRE Name for this Vulnerability > >The Common Vulnerabilities and Exposures project has assigned the >name CAN-2005-3056 to this vulnerability. > > >---++ Details > >The TWiki INCLUDE function enables a malicious user to compose a >command line executed by the Perl backtick (``) operator. > >The rev parameter of the INCLUDE variable is not checked properly >for shell metacharacters and is thus vulnerable to revision >numbers containing pipes and shell commands. The exploit is >possible on included topics with two or more revisions. > >Example INCLUDE variable exploiting the rev parameter: >%INCLUDE{ "Main.TWikiUsers" rev="2|less /etc/passwd" }% > >The same vulnerability is exposed to all Plugins and add-ons that >use TWiki::Func::readTopicText[8] function to read a previous topic >revision. This has been tested on TWiki:Plugins.RevCommentPlugin[9] >and TWiki:Plugins.CompareRevisionsAddon[10]. > >If access to TWiki is not restricted by other means, attackers can >use the revision function with or without prior authentication, >depending on the configuration. > >See Also: > * IncludePreviousTopicRevision[11] > * SecurityAlertExecuteCommandsWithRev[12] > * SecurityAlertExecuteCommandsWithSearch[13] > * UncoordinatedSecurityAlert23Feb2005[7] > > >---++ Countermeasures > > * Apply hotfix (see patches below) > * NOTE: The hotfix is known to prevent the current attacks, > but it might not be a complete fix > * Upgrade to the latest patched production TWikiRelease04Sep2004[1] > * NOTE: If you are running an *unmodified* > TWikiRelease01Sep2004[4], TWikiRelease02Sep2004[3] or > TWikiRelease03Sep2004[2], simply copy the following patched > files from TWikiRelease04Sep2004 to your installation: > lib/TWiki.pm, lib/TWiki/Store.pm, lib/TWiki/UI/RDiff.pm, > lib/TWiki/UI/View.pm, lib/TWiki/UI/Viewfile.pm > * Apply patch of UncoordinatedSecurityAlert23Feb2005[7] (but see > known issues of that patch) > * Filter access to the web server > * Use the web server software to restrict access to the web pages > served by TWiki > >---++ Authors and Credits > > * Credit to TWiki:Main.JChristophFuchs (jcf@ipp.mpg.de) and > TWiki:Main.JoseLuna (luna@aditel.org) for disclosing the issue > to the twiki-security@lists.sourceforge.net mailing list > * TWiki:Main.JoseLuna for contributing a more robust patch to > recent SecurityAlertExecuteCommandsWithRev[12] issue (included > in this patch) > * TWiki:Main.PeterThoeny, TWiki:Main.JoseLuna, > TWiki:Main.CrawfordCurrie for contributing to the advisory and > the patch > > >---++ Hotfix > >---+++ Patch for TWiki Production Release 03-Sep-2004 > >Affected files: twiki/lib/TWiki.pm, twiki/lib/TWiki/Store.pm, >lib/TWiki/UI/RDiff.pm, lib/TWiki/UI/View.pm, >lib/TWiki/UI/Viewfile.pm > >See attached patch file TWiki200409-03-04patch.txt > > >---+++ Patch for TWiki Production Release 02-Sep-2004 > >Affected files: twiki/lib/TWiki.pm, twiki/lib/TWiki/Store.pm, >lib/TWiki/UI/RDiff.pm, lib/TWiki/UI/View.pm, >lib/TWiki/UI/Viewfile.pm > >See attached patch file TWiki200409-02-04patch.txt > > >---+++ Patch for TWiki Production Release 01-Feb-2003 > >__Note:__ This assumes that the release is already patched with >SecurityAlertExecuteCommandsWithRev[12] fix. > >Affected files: twiki/lib/TWiki/Store.pm, twiki/bin/rdiff, >twiki/bin/view, twiki/bin/viewfil= > >See attached patch file TWiki200302-01-04patch.txt > > >---++ TWiki News > > * A new TWiki release is upcoming soon, code named DakarRelease[6] > * To customize your TWiki installation, TWiki.org offers now > 177 Plugin packages[14], 56 Add-on packages[15], 30 Skin > packages[16], and 11 TWiki contrib packages [17] > * Codev.TWikiSecurityAlertProcess[18] documents our security > process > * Wikis and TWiki get covered more my the press[19] > * TWiki is represented at the International Symposium on Wikis[20] > in San Diego, 17-18 Oct 2005 > * A new book on Wikis in the Workplace is in work[21] > >Best regards, >Peter > > >[1]: http://twiki.org/cgi-bin/view/Codev/TWikiRelease04Sep2004 >[2]: http://twiki.org/cgi-bin/view/Codev/TWikiRelease03Sep2004 >[3]: http://twiki.org/cgi-bin/view/Codev/TWikiRelease02Sep2004 >[4]: http://twiki.org/cgi-bin/view/Codev/TWikiRelease01Sep2004 >[5]: http://twiki.org/cgi-bin/view/Codev/TWikiRelease01Feb2003 >[6]: http://twiki.org/cgi-bin/view/Codev/DakarReleases >[7]: http://twiki.org/cgi-bin/view/Codev/UncoordinatedSecurityAlert23Feb2005 >[8]: http://twiki.org/cgi-bin/view/TWiki/TWikiFuncModule >[9]: http://twiki.org/cgi-bin/view/Plugins/RevCommentPlugin >[10]: http://twiki.org/cgi-bin/view/Plugins/CompareRevisionsAddon >[11]: http://twiki.org/cgi-bin/view/Codev/IncludePreviousTopicRevision >[12]: http://twiki.org/cgi-bin/view/Codev/SecurityAlertExecuteCommandsWithRev >[13]: >http://twiki.org/cgi-bin/view/Codev/SecurityAlertExecuteCommandsWithSearch >[14]: http://twiki.org/cgi-bin/view/Plugins/PluginPackage >[15]: http://twiki.org/cgi-bin/view/Plugins/AddOnPackage >[16]: http://twiki.org/cgi-bin/view/Plugins/SkinPackage >[17]: http://twiki.org/cgi-bin/view/Plugins/ContribPackage >[18]: http://twiki.org/cgi-bin/view/Codev/TWikiSecurityAlertProcess >[19]: http://twiki.org/cgi-bin/view/Codev/TWikiInTheNews >[20]: http://twiki.org/cgi-bin/view/Codev/InternationalSymposiumOnWikis >[21]: http://twiki.org/cgi-bin/view/Codev/WikisInTheWorkplaceBook > > >-- > * Peter Thoeny Peter@Thoeny.com > * Is your team already TWiki enabled? http://TWiki.org > * This e-mail is: (x) public (_) ask first (_) private >--- ../rel20040903/TWikiDocumentation.html Fri Sep 9 18:09:15 2005 >+++ ./TWikiDocumentation.html Tue Sep 20 16:32:36 2005 >@@ -1,7 +1,7 @@ > > TWikiDocumentation > >-

name="_TWiki_Reference_Manual_03_Sep_2"> TWiki Reference Manual (03 >Sep 2004 $Rev: 1742 $)

>+

name="_TWiki_Reference_Manual_04_Sep_2"> TWiki Reference Manual (04 >Sep 2004 $Rev: 1742 $)

>

>