From fenner at research.att.com Mon Apr 1 09:16:06 2002 From: fenner at research.att.com (Bill Fenner) Date: Mon, 1 Apr 2002 09:16:06 -0800 Subject: Anyone seen this problem before ? Message-ID: <200204011716.JAA05416@windsor.research.att.com> If you don't have both flex and bison installed, both libpcap and bro will use the system lex/yacc. The system lex/yacc don't support multiple parsers in the same executable. I wonder if bro's configure script should insist on flex/bison, since it knows that it'll be linked with libpcap which already has a parser, and if both are compiled with the system lex/yacc you will get errors like this. Bill From vern at icir.org Mon Apr 1 22:51:53 2002 From: vern at icir.org (Vern Paxson) Date: Mon, 01 Apr 2002 22:51:53 -0800 Subject: bit manipulation in bro scripts. In-Reply-To: Your message of Sat, 30 Mar 2002 01:17:17 EST. Message-ID: <200204020651.g326prO23843@yak.icir.org> > does bro scripts support bit manipulation ? > for eg: to see if the nth bit is set/not ? Only via mask_addr(), which just lops off least significant bits. Adding some built-in functions to do this would be quite easy, though. Just use mask_addr() as a template for how to do it. Vern From vern at icir.org Mon Apr 1 22:50:56 2002 From: vern at icir.org (Vern Paxson) Date: Mon, 01 Apr 2002 22:50:56 -0800 Subject: Anyone seen this problem before ? In-Reply-To: Your message of Mon, 01 Apr 2002 09:16:06 PST. Message-ID: <200204020650.g326ouO23818@yak.icir.org> > I wonder if bro's configure script should insist on flex/bison, > since it knows that it'll be linked with libpcap which already has > a parser, and if both are compiled with the system lex/yacc you will > get errors like this. Yep, you're right, it should. The fallback to lex/yacc is vestigial. If someone wants to contribute the right configure tweak to enforce flex/bison, that would be cool .... Vern From vern at icir.org Mon Apr 1 22:56:01 2002 From: vern at icir.org (Vern Paxson) Date: Mon, 01 Apr 2002 22:56:01 -0800 Subject: bro variable. In-Reply-To: Your message of Sun, 31 Mar 2002 15:55:42 EST. Message-ID: <200204020656.g326u1O23940@yak.icir.org> > int var; > > var = opt_internal_int("var"); > > -------------------------------------- > > Now if i change var in the any of the .cc files does the change reflect at > the policy level ? No, it doesn't. (This is implicitly apparent from the type signature of opt_internal_int() - it returns an int, not an int&, so there's no way for an assignment to the C++ variable "var" to affect any other value. > **Otherwise is there a way to share a variable between the .cc files and > the policy scripts ?? ** There is no simple mechanism to reflect changes to a C++ variable into a Bro policy script variable. To do so, you have to locate the corresponding Bro variable and invoke the Assign() method on it. Vern From athomas at unity.ncsu.edu Sat Apr 13 16:05:26 2002 From: athomas at unity.ncsu.edu (Ashley Thomas) Date: Sat, 13 Apr 2002 19:05:26 -0400 (EDT) Subject: bro: defragmentation In-Reply-To: <200202080746.g187kxC10137@yak.icir.org> Message-ID: If we have a user-controllable timeout, will that be a timeout for the whole datagram to reassemlbed (ie within that 'N' secs all the fragments should be reassemled) OR will the timer be started again if we get another fragment within that 'N' secs. -ashley On Thu, 7 Feb 2002, Vern Paxson wrote: > > How long does Bro keep ip-fragments ? > > Forever. > > This isn't great - clearly there should be a user-controllable timeout. > However, if you set the timeout too low, then you become vulnerable to an > evasion attack. It's not clear what's a safe timeout value (some stacks > might use a fixed-size buffer, say, and ignore implementing a timer at > all). A project I'm working on with a student (Umesh Shankar) may wind > up assessing this further. > > If someone wants to add a user-controllable timeout, that would be great. > > Vern > From athomas at unity.ncsu.edu Sun Apr 14 18:55:00 2002 From: athomas at unity.ncsu.edu (Ashley Thomas) Date: Sun, 14 Apr 2002 21:55:00 -0400 (EDT) Subject: bro: fragmentation-reassembly timeout impl. In-Reply-To: <200202080746.g187kxC10137@yak.icir.org> Message-ID: Hi, As suggested by Vern, I have added a user controllable timeout for the fragmentation reassembly part of Bro. I hope this will be useful. While adding this feature, I have modified the following files: Frag.cc Frag.h Sessions.cc NetVar.cc NetVar.h policy/bro.init I have attached the above files and their *diff* with the original files (from version bro-pub-0.7a90) All the files are attached a gzipped tar file. The original version keeps the fragments in memory till it gets fully reassembled (without a timeout). Therefore i tried the following attack on it; ie.sent a large number of ip-fragments (without completing the full datagram). It was seen that the memory consumed by bro increased consistently till the machine crashed. After the timer has been added, I have verified that it works the expected way for fully reassembl-able fragments (nothing broken !) as well as it removes the not re-assembled fragments after a user controlled timeout. The implementaion has been done very much similar to how it has been done for the tcp connection. A timer (user defined) is started (in FragReassembler constructor) when it gets a fragment for a new set < src ip, dst ip, ID, protocol > and if the reassembly is not complete within the user specified timeout, the resources allotted for this set is destroyed. I have done testing of the same. Hope this is helpful.Please let me know if there is any problems/modifications needed. cheers ashley On Thu, 7 Feb 2002, Vern Paxson wrote: > > How long does Bro keep ip-fragments ? > > Forever. > > This isn't great - clearly there should be a user-controllable timeout. > However, if you set the timeout too low, then you become vulnerable to an > evasion attack. It's not clear what's a safe timeout value (some stacks > might use a fixed-size buffer, say, and ignore implementing a timer at > all). A project I'm working on with a student (Umesh Shankar) may wind > up assessing this further. > > If someone wants to add a user-controllable timeout, that would be great. > > Vern > From athomas at unity.ncsu.edu Sun Apr 14 18:58:08 2002 From: athomas at unity.ncsu.edu (Ashley Thomas) Date: Sun, 14 Apr 2002 21:58:08 -0400 (EDT) Subject: Bro fragmentation reassembly impl (sorry prev mail missed the attachment!) In-Reply-To: <200202080746.g187kxC10137@yak.icir.org> Message-ID: Hi, As suggested by Vern, I have added a user controllable timeout for the fragmentation reassembly part of Bro. I hope this will be useful. While adding this feature, I have modified the following files: Frag.cc Frag.h Sessions.cc NetVar.cc NetVar.h policy/bro.init I have attached the above files and their *diff* with the original files (from version bro-pub-0.7a90) All the files are attached a gzipped tar file. The original version keeps the fragments in memory till it gets fully reassembled (without a timeout). Therefore i tried the following attack on it; ie.sent a large number of ip-fragments (without completing the full datagram). It was seen that the memory consumed by bro increased consistently till the machine crashed. After the timer has been added, I have verified that it works the expected way for fully reassembl-able fragments (nothing broken !) as well as it removes the not re-assembled fragments after a user controlled timeout. The implementaion has been done very much similar to how it has been done for the tcp connection. A timer (user defined) is started (in FragReassembler constructor) when it gets a fragment for a new set < src ip, dst ip, ID, protocol > and if the reassembly is not complete within the user specified timeout, the resources allotted for this set is destroyed. I have done testing of the same. Hope this is helpful.Please let me know if there is any problems/modifications needed. cheers ashley On Thu, 7 Feb 2002, Vern Paxson wrote: > > How long does Bro keep ip-fragments ? > > Forever. > > This isn't great - clearly there should be a user-controllable timeout. > However, if you set the timeout too low, then you become vulnerable to an > evasion attack. It's not clear what's a safe timeout value (some stacks > might use a fixed-size buffer, say, and ignore implementing a timer at > all). A project I'm working on with a student (Umesh Shankar) may wind > up assessing this further. > > If someone wants to add a user-controllable timeout, that would be great. > > Vern > -------------- next part -------------- A non-text attachment was scrubbed... Name: frag.tar.gz Type: application/octet-stream Size: 18220 bytes Desc: frag.tar.gz Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20020414/4fd28ca1/attachment.obj From jh0u at hotmail.com Fri Apr 26 17:11:43 2002 From: jh0u at hotmail.com (jd ls) Date: Fri, 26 Apr 2002 17:11:43 -0700 Subject: inquiry Message-ID: Hi, I wish to test and build bro for debian/gnu linux but I ran into a couple of problems... hope somebody can help me out. 1.after ./configure I get something like: creating ./config.status creating Makefile creating aux/hf/Makefile sed: can't read ./aux/hf/Makefile.in: No such file or directory creating aux/cf/Makefile creating config.h config.h is unchanged my question is, should I be worried about sed not being able to read ./aux/hf/Makefile.in? 2.after ignoring the above error, continuing with make fails at sup3r:/idsbro/bro-pub-0.7a90# make c++ -I. -O -Ilinux-include -c Func.cc Func.cc: In function `void do_fmt(const char *&, Val *, ODesc *)': Func.cc:247: implicit declaration of function `int localtime(...)' Func.cc:247: implicit declaration of function `int strftime(...)' make: *** [Func.o] Error 1 is that related to the first problem or it's another problem I need to deal with and I honestly don't know how... thanks for any help _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From jh0u at hotmail.com Sat Apr 27 15:44:44 2002 From: jh0u at hotmail.com (jd ls) Date: Sat, 27 Apr 2002 15:44:44 -0700 Subject: inquiry Message-ID: Hi, I just included and it compiles ok now with some warnings but that's ok... Thanks Again! > >Hi, > >I wish to test and build bro for debian/gnu linux but I ran into a couple >of >problems... hope somebody can help me out. > >1.after ./configure I get something like: >creating ./config.status >creating Makefile >creating aux/hf/Makefile >sed: can't read ./aux/hf/Makefile.in: No such file or directory >creating aux/cf/Makefile >creating config.h >config.h is unchanged > >my question is, should I be worried about sed not being able to read >./aux/hf/Makefile.in? > >2.after ignoring the above error, continuing with make fails at > >sup3r:/idsbro/bro-pub-0.7a90# make >c++ -I. -O -Ilinux-include -c Func.cc >Func.cc: In function `void do_fmt(const char *&, Val *, ODesc *)': >Func.cc:247: implicit declaration of function `int localtime(...)' >Func.cc:247: implicit declaration of function `int strftime(...)' >make: *** [Func.o] Error 1 > >is that related to the first problem or it's another problem I need to deal >with and I honestly don't know how... > >thanks for any help > _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com