From Chris.Manders at UnixHelpDesk.COM Sat Jul 5 19:42:23 2003 From: Chris.Manders at UnixHelpDesk.COM (Christopher Jay Manders) Date: Sat, 05 Jul 2003 19:42:23 -0700 Subject: BRA: The Bro Re-usable Architecture (release 0.1a) -- A set of scripts to help in using and setting up a Bro environment. Message-ID: <3F078C8F.9020606@UnixHelpDesk.COM> Hi, I have been toying with a set of scripts for some time now to help those that use or plan to use bro. In my opinion, there needs to be more consistency in bro implementations (I have now seen a few) to actually be able to provide any further supplementary scripts and applications that can help in making the use of bro as effective as possible. What I have done is to compile a set of scripts that comprise a base environment in which bro can run. Since they get bro up and going with many re-usable aspects, I have dubbed my set of scripts BRA (the Bro Re-usable Architecture). These scripts are meant to compliment the use of bro in an environment and are independent of any bro policies used. The main features of BRA are: 1) The BRA environment encapsulates and provides wrapper functions for running Bro. 2) All of the scripts are written in PERL for consistency. 3) All of the scripts use one single configuration file (~/etc/config.cf). 4) All of the scripts are meant to be small and take up little disk space, memory and cpu. 5) Provide a means to 'checkpoint' or 'restart' a Bro instantiation without loss of network traffic analysis. 6) Provide a default set of reports that are sent to those using Bro (coming in next release). 7) Help organize the log files for later use. Please feel free to download the initial BRA release (this is a very early alpha release) from here: http://www.UnixHelpDesk.COM/~cmanders/projects/bra.html This is just the bare-bones version that I am releasing, as I have a more robust setup for myself. Eventually I'll add the pieces that make the most sense, or that are found to be the most useful, in updates. I am very interested in feedback, suggestions or other comments to further provide a bro environment that folks find to be pleasing and useful. NOTE: The BRA setup does not provide any software such as bro. You will need to download and compile bro independently. Cheers! Christopher From jmellander at lbl.gov Fri Jul 11 15:34:26 2003 From: jmellander at lbl.gov (Jim Mellander) Date: Fri, 11 Jul 2003 15:34:26 -0700 Subject: Bro <-> Snort documentation References: <200307021924.h62JOrw9014633@jaguar.icir.org> Message-ID: <3F0F3B72.511EAB1B@lbl.gov> I sent this to Vern, but thought a wider audience might be interested, or have some answers. Thanks Vern: I'm planning on using the snort engine to extend KO (Kazaa Obliterator). It looks like I could use a policy script like this: signature kazaa-seen { ip-proto == tcp dst-ip == whatever dst-port == whatever (or omitted, I guess) payload /.*kazaa regular expression/ eval function_to_execute_when_kazaa_seen event "kazaa seen" } The 'eval' & the 'event' are somewhat confusing. I presume that the 'signature_match' event is triggered with the string for action, but when is the 'eval' called (before the event, or after), and with what args? Presumably the connection information is available. I haven't seen any running examples of the signature event. Do you have some examples? Thanks. -- Jim Mellander Incident Response Manager Computer Protection Program Lawrence Berkeley National Laboratory (510) 486-7204 Your fortune for today is: The longest part of the journey is said to be the passing of the gate. -- Marcus Terentius Varro From wsffree at hotmail.com Sat Jul 12 01:56:48 2003 From: wsffree at hotmail.com (Wang Shaofu) Date: Sat, 12 Jul 2003 16:56:48 +0800 Subject: "for and while" in Bro language Message-ID: Hi all Does Bro have the loop language of "for" or "while" (like the for and while in C++ language)? Thanks Have a nice day! -- Cloud _________________________________________________________________ ?????????????? MSN Messenger: http://messenger.msn.com/cn From Chris.Manders at UnixHelpDesk.COM Sat Jul 12 08:20:33 2003 From: Chris.Manders at UnixHelpDesk.COM (Christopher Jay Manders) Date: Sat, 12 Jul 2003 08:20:33 -0700 Subject: Errors compiling bro-pub-0.8a32 on Linux 2.4.20-8 Message-ID: <3F102741.4050003@UnixHelpDesk.COM> Hi, Just thought I would note that for several versions of Linux, the compile does not work out of the box. Not just kernel 2.4.20-8. But, this is the one I am going to do some testing on. I will be doing my IDS testing on: 1 - FreeBSD 4.6.2 1 - OpenBSD 2.9 1 - Linux 2.4.20-8 Anyway, the configure goes ok on Linux, but the initial make gets the errors below. I hope they are useful to get the autoconf stuff setup right for the next release. If you can offer where to fix this, I'd be happy. Otherwise, if I get a chance I'd figure that out and send the fix. At first glance it looks like the static use of the linux-includes does not scale past some certain Linux version. HTH Chris The problems start here: g++ -I. -Ilibedit -O -Ilinux-include -c main.cc g++ -I. -Ilibedit -O -Ilinux-include -c net_util.cc g++ -I. -Ilibedit -O -Ilinux-include -c util.cc util.cc: In function `void init_random_seed()': util.cc:395: `uint32_t' undeclared (first use this function) util.cc:395: (Each undeclared identifier is reported only once for each function it appears in.) util.cc:395: parse error before `[' token util.cc:399: `buf' undeclared (first use this function) util.cc:427: parse error before `=' token util.cc:430: `result' undeclared (first use this function) make: *** [util.o] Error 1 Full log: Unpacking libedit sources Building libedit.a creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for gawk... gawk checking for a BSD compatible install... /usr/bin/install -c checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking for limits.h... yes checking for malloc.h... yes checking for sys/ioctl.h... yes checking for unistd.h... yes checking for sys/cdefs.h... yes checking for sys/types.h... yes checking for working const... yes checking for size_t... yes checking for working alloca.h... yes checking for alloca... yes checking whether gcc needs -traditional... no checking return type of signal handlers... void checking for re_comp... yes checking for regcomp... yes checking for strdup... yes checking for strerror... yes checking for strstr... yes checking for strtol... yes checking for vis.h... no checking for strlcat... no checking for strlcpy... no checking for issetugid... no checking for fgetln... no checking for getline... yes checking for flockfile... yes updating cache ./config.cache creating ./config.status creating Makefile creating compat_conf.h make[1]: Entering directory `/home/cmanders/bro-pub-0.8a32/libedit' sh ./makelist -h ./vi.c > vi.h.tmp && \ mv vi.h.tmp vi.h sh ./makelist -h ./emacs.c > emacs.h.tmp && \ mv emacs.h.tmp emacs.h sh ./makelist -h ./common.c > common.h.tmp && \ mv common.h.tmp common.h sh ./makelist -fh vi.h emacs.h common.h > fcns.h.tmp && \ mv fcns.h.tmp fcns.h sh ./makelist -bh ./vi.c ./emacs.c ./common.c > help.h.tmp && \ mv help.h.tmp help.h sh ./makelist -bc ./vi.c ./emacs.c ./common.c > help.c.tmp && \ mv help.c.tmp help.c gcc -g -O2 -I. -I. -g -O0 -c chared.c gcc -g -O2 -I. -I. -g -O0 -c common.c gcc -g -O2 -I. -I. -g -O0 -c el.c gcc -g -O2 -I. -I. -g -O0 -c emacs.c sh ./makelist -fc vi.h emacs.h common.h > fcns.c.tmp && \ mv fcns.c.tmp fcns.c gcc -g -O2 -I. -I. -g -O0 -c fcns.c gcc -g -O2 -I. -I. -g -O0 -c hist.c gcc -g -O2 -I. -I. -g -O0 -c history.c gcc -g -O2 -I. -I. -g -O0 -c key.c gcc -g -O2 -I. -I. -g -O0 -c map.c gcc -g -O2 -I. -I. -g -O0 -c parse.c gcc -g -O2 -I. -I. -g -O0 -c prompt.c gcc -g -O2 -I. -I. -g -O0 -c read.c gcc -g -O2 -I. -I. -g -O0 -c refresh.c gcc -g -O2 -I. -I. -g -O0 -c search.c gcc -g -O2 -I. -I. -g -O0 -c sig.c gcc -g -O2 -I. -I. -g -O0 -c term.c gcc -g -O2 -I. -I. -g -O0 -c tokenizer.c gcc -g -O2 -I. -I. -g -O0 -c tty.c gcc -g -O2 -I. -I. -g -O0 -c vi.c gcc -g -O2 -I. -I. -g -O0 -c help.c gcc -g -O2 -I. -I. -g -O0 -c fgetln.c gcc -g -O2 -I. -I. -g -O0 -c readline.c gcc -g -O2 -I. -I. -g -O0 -c strlcpy.c ar -r libedit.a chared.o common.o el.o emacs.o fcns.o hist.o history.o key.o map.o parse.o prompt.o read.o refresh.o search.o sig.o term.o tokenizer.o tty.o vi.o help.o fgetln.o readline.o strlcpy.o make[1]: Leaving directory `/home/cmanders/bro-pub-0.8a32/libedit' bison -y -d -t -v builtin-func.y flex -obif_lex.cc builtin-func.l g++ -o bif_lex.o -c bif_lex.cc g++ -o bif_parse.o -c bif_parse.cc g++ -o bif_arg.o -c bif_arg.cc g++ -I. -Ilibedit -O -Ilinux-include -o bifcl bif_lex.o bif_parse.o bif_arg.o ./bifcl event.bif ./bifcl const.bif g++ -I. -Ilibedit -O -Ilinux-include -c main.cc g++ -I. -Ilibedit -O -Ilinux-include -c net_util.cc g++ -I. -Ilibedit -O -Ilinux-include -c util.cc util.cc: In function `void init_random_seed()': util.cc:395: `uint32_t' undeclared (first use this function) util.cc:395: (Each undeclared identifier is reported only once for each function it appears in.) util.cc:395: parse error before `[' token util.cc:399: `buf' undeclared (first use this function) util.cc:427: parse error before `=' token util.cc:430: `result' undeclared (first use this function) make: *** [util.o] Error 1 From Chris.Manders at UnixHelpDesk.COM Sat Jul 12 08:25:02 2003 From: Chris.Manders at UnixHelpDesk.COM (Christopher Jay Manders) Date: Sat, 12 Jul 2003 08:25:02 -0700 Subject: Errors compiling Bro on OpenBSD 2.9 Message-ID: <3F10284E.90503@UnixHelpDesk.COM> Hi, Ok, I had moved on to FreeBSD and OpenBSD. The FreeBSD Bro compile works like a champ. The OpenBSD compile gets the following errors, relating to BIND defines and such. Any thoughts to fix these (or the Linux) compiles would be most helpful. Tx! Chris Errors on OpenBSD compile: creating ./config.status creating Makefile creating compat_conf.h compat_conf.h is unchanged ar -r libedit.a chared.o common.o el.o emacs.o fcns.o hist.o history.o key.o map.o parse.o prompt.o read.o refresh.o search.o sig.o term.o tokenizer.o tty.o vi.o help.o fgetln.o readline.o strlcpy.o gcc -I. -Ilibedit -O -c nb_dns.c nb_dns.c:81: `NS_MAXDNAME' undeclared here (not in a function) nb_dns.c:81: size of array `name' has non-integer type nb_dns.c: In function `_nb_dns_mkquery': nb_dns.c:274: `NS_INADDRSZ' undeclared (first use in this function) nb_dns.c:274: (Each undeclared identifier is reported only once nb_dns.c:274: for each function it appears in.) nb_dns.c:279: `NS_IN6ADDRSZ' undeclared (first use in this function) nb_dns.c:291: `ns_o_query' undeclared (first use in this function) nb_dns.c:293: `ns_c_in' undeclared (first use in this function) nb_dns.c: In function `nb_dns_addr_request2': nb_dns.c:376: `NS_MAXDNAME' undeclared (first use in this function) nb_dns.c:376: size of array `name' has non-integer type nb_dns.c:394: `NS_IN6ADDRSZ' undeclared (first use in this function) nb_dns.c: In function `nb_dns_activity': nb_dns.c:457: syntax error before `handle' nb_dns.c:473: `handle' undeclared (first use in this function) nb_dns.c:516: `ns_f_rcode' undeclared (first use in this function) nb_dns.c:518: `ns_r_nxdomain' undeclared (first use in this function) nb_dns.c:523: `ns_r_servfail' undeclared (first use in this function) nb_dns.c:528: `ns_r_noerror' undeclared (first use in this function) nb_dns.c:531: `ns_r_formerr' undeclared (first use in this function) nb_dns.c:532: `ns_r_notimpl' undeclared (first use in this function) nb_dns.c:533: `ns_r_refused' undeclared (first use in this function) nb_dns.c:519: warning: unreachable code at beginning of switch statement nb_dns.c:541: `rr' undeclared (first use in this function) nb_dns.c:556: `ns_s_an' undeclared (first use in this function) nb_dns.c:572: warning: assignment makes pointer from integer without a cast *** Error code 1 From Chris.Manders at UnixHelpDesk.COM Sat Jul 12 08:33:58 2003 From: Chris.Manders at UnixHelpDesk.COM (Christopher Jay Manders) Date: Sat, 12 Jul 2003 08:33:58 -0700 Subject: "for and while" in Bro language (and threading?) In-Reply-To: References: Message-ID: <3F102A66.2080802@UnixHelpDesk.COM> Hi, Really good question! Either one, or both, would be extremely useful as far as I can see. I suppose there are reasons that these are not included, and it would be good to know those reasons. I assume that it is so that someone can't blow a hole in their foot, since if one doesn't do bounds checks, Bro would probably freak out. It would be nice if the actual bro pieces were threaded for various reasons. I'd assume that if it were a completely threaded app that the crashing behavior it seems to exhibit during load, the packet dropping, and other aspects could be seriously improved. But, that is jsut my $.02. Certainly to split off the BPF code into a spearate thread would allow it to read on ahead and not loose as much network traffic on a busy network while the actual parser/analyzers could be chugging along merrily in another (or other) thread/s. Anyone have the reasons that there is no for or while loops? And, what should be substituted in their place? Tx! Chris > Hi all > Does Bro have the loop language of "for" or "while" (like the for > and while in C++ language)? > > Thanks > Have a nice day! > -- Cloud > > _________________________________________________________________ > ?????????????? MSN Messenger: http://messenger.msn.com/cn From Chris.Manders at UnixHelpDesk.COM Sat Jul 12 09:05:58 2003 From: Chris.Manders at UnixHelpDesk.COM (Christopher Jay Manders) Date: Sat, 12 Jul 2003 09:05:58 -0700 Subject: Denial of Service on Bro via Scott Crosby and Dan Wallach's method...fixed in bro-pub-0.8a32? Message-ID: <3F1031E6.5080607@UnixHelpDesk.COM> Hi, I am interested to do some further testing of this, but does the a32 release have the fixes for the hashing issue inside? (I am referring to their paper at: http://www.cs.rice.edu/~scrosby/hash/.) Has this been extensively tested? Tx! Chris From Chris.Manders at UnixHelpDesk.COM Sat Jul 12 09:19:45 2003 From: Chris.Manders at UnixHelpDesk.COM (Christopher Jay Manders) Date: Sat, 12 Jul 2003 09:19:45 -0700 Subject: Errors compiling bro-pub-0.8a32 on Linux 2.4.20-8 In-Reply-To: <3F102741.4050003@UnixHelpDesk.COM> References: <3F102741.4050003@UnixHelpDesk.COM> Message-ID: <3F103521.6040101@UnixHelpDesk.COM> I fixed this by adding: #include to the top of util.cc, since that is where uint32_t is defined on my Linux.... That solved that problem. Then another cropped up in Dict.cc: g++ -I. -Ilibedit -O -Ilinux-include -c Dict.cc Dict.cc: In member function `void* Dictionary::NextEntry(HashKey*&, IterCookie*&, int) const': Dict.cc:260: choosing `HashKey::HashKey(const void*, int, unsigned int)' over ` HashKey::HashKey(void*, int, int)' Dict.cc:260: because worst conversion for the former is better than worst conversion for the latter Dict.cc:288: choosing `HashKey::HashKey(const void*, int, unsigned int)' over ` HashKey::HashKey(void*, int, int)' Dict.cc:288: because worst conversion for the former is better than worst conversion for the latter make: *** [Dict.o] Error 1 This error looks more programatic to fix, so this will take more time. Anyone with thoughts on this one? Tx! Chris > Hi, > > Just thought I would note that for several versions of Linux, the > compile does not work out of the box. Not just kernel 2.4.20-8. But, > this is the one I am going to do some testing on. > > I will be doing my IDS testing on: > 1 - FreeBSD 4.6.2 > 1 - OpenBSD 2.9 > 1 - Linux 2.4.20-8 > > Anyway, the configure goes ok on Linux, but the initial make gets the > errors below. I hope they are useful to get the autoconf stuff setup > right for the next release. > > If you can offer where to fix this, I'd be happy. Otherwise, if I get a > chance I'd figure that out and send the fix. At first glance it looks > like the static use of the linux-includes does not scale past some > certain Linux version. > > HTH > > > Chris > > > The problems start here: > g++ -I. -Ilibedit -O -Ilinux-include -c main.cc > g++ -I. -Ilibedit -O -Ilinux-include -c net_util.cc > g++ -I. -Ilibedit -O -Ilinux-include -c util.cc > util.cc: In function `void init_random_seed()': > util.cc:395: `uint32_t' undeclared (first use this function) > util.cc:395: (Each undeclared identifier is reported only once for each > function it appears in.) > util.cc:395: parse error before `[' token > util.cc:399: `buf' undeclared (first use this function) > util.cc:427: parse error before `=' token > util.cc:430: `result' undeclared (first use this function) > make: *** [util.o] Error 1 > > > > > > Full log: > Unpacking libedit sources > Building libedit.a > creating cache ./config.cache > checking for gcc... gcc > checking whether the C compiler (gcc ) works... yes > checking whether the C compiler (gcc ) is a cross-compiler... no > checking whether we are using GNU C... yes > checking whether gcc accepts -g... yes > checking for gawk... gawk > checking for a BSD compatible install... /usr/bin/install -c > checking for dirent.h that defines DIR... yes > checking for opendir in -ldir... no > checking how to run the C preprocessor... gcc -E > checking for ANSI C header files... yes > checking for sys/wait.h that is POSIX.1 compatible... yes > checking for limits.h... yes > checking for malloc.h... yes > checking for sys/ioctl.h... yes > checking for unistd.h... yes > checking for sys/cdefs.h... yes > checking for sys/types.h... yes > checking for working const... yes > checking for size_t... yes > checking for working alloca.h... yes > checking for alloca... yes > checking whether gcc needs -traditional... no > checking return type of signal handlers... void > checking for re_comp... yes > checking for regcomp... yes > checking for strdup... yes > checking for strerror... yes > checking for strstr... yes > checking for strtol... yes > checking for vis.h... no > checking for strlcat... no > checking for strlcpy... no > checking for issetugid... no > checking for fgetln... no > checking for getline... yes > checking for flockfile... yes > updating cache ./config.cache > creating ./config.status > creating Makefile > creating compat_conf.h > make[1]: Entering directory `/home/cmanders/bro-pub-0.8a32/libedit' > sh ./makelist -h ./vi.c > vi.h.tmp && \ > mv vi.h.tmp vi.h > sh ./makelist -h ./emacs.c > emacs.h.tmp && \ > mv emacs.h.tmp emacs.h > sh ./makelist -h ./common.c > common.h.tmp && \ > mv common.h.tmp common.h > sh ./makelist -fh vi.h emacs.h common.h > fcns.h.tmp && \ > mv fcns.h.tmp fcns.h > sh ./makelist -bh ./vi.c ./emacs.c ./common.c > help.h.tmp && \ > mv help.h.tmp help.h > sh ./makelist -bc ./vi.c ./emacs.c ./common.c > help.c.tmp && \ > mv help.c.tmp help.c > gcc -g -O2 -I. -I. -g -O0 -c chared.c > gcc -g -O2 -I. -I. -g -O0 -c common.c > gcc -g -O2 -I. -I. -g -O0 -c el.c > gcc -g -O2 -I. -I. -g -O0 -c emacs.c > sh ./makelist -fc vi.h emacs.h common.h > fcns.c.tmp && \ > mv fcns.c.tmp fcns.c > gcc -g -O2 -I. -I. -g -O0 -c fcns.c > gcc -g -O2 -I. -I. -g -O0 -c hist.c > gcc -g -O2 -I. -I. -g -O0 -c history.c > gcc -g -O2 -I. -I. -g -O0 -c key.c > gcc -g -O2 -I. -I. -g -O0 -c map.c > gcc -g -O2 -I. -I. -g -O0 -c parse.c > gcc -g -O2 -I. -I. -g -O0 -c prompt.c > gcc -g -O2 -I. -I. -g -O0 -c read.c > gcc -g -O2 -I. -I. -g -O0 -c refresh.c > gcc -g -O2 -I. -I. -g -O0 -c search.c > gcc -g -O2 -I. -I. -g -O0 -c sig.c > gcc -g -O2 -I. -I. -g -O0 -c term.c > gcc -g -O2 -I. -I. -g -O0 -c tokenizer.c > gcc -g -O2 -I. -I. -g -O0 -c tty.c > gcc -g -O2 -I. -I. -g -O0 -c vi.c > gcc -g -O2 -I. -I. -g -O0 -c help.c > gcc -g -O2 -I. -I. -g -O0 -c fgetln.c > gcc -g -O2 -I. -I. -g -O0 -c readline.c > gcc -g -O2 -I. -I. -g -O0 -c strlcpy.c > ar -r libedit.a chared.o common.o el.o emacs.o fcns.o hist.o history.o > key.o map.o parse.o prompt.o read.o refresh.o search.o sig.o term.o > tokenizer.o tty.o vi.o help.o fgetln.o readline.o strlcpy.o > make[1]: Leaving directory `/home/cmanders/bro-pub-0.8a32/libedit' > bison -y -d -t -v builtin-func.y > flex -obif_lex.cc builtin-func.l > g++ -o bif_lex.o -c bif_lex.cc > g++ -o bif_parse.o -c bif_parse.cc > g++ -o bif_arg.o -c bif_arg.cc > g++ -I. -Ilibedit -O -Ilinux-include -o bifcl bif_lex.o bif_parse.o > bif_arg.o > ./bifcl event.bif > ./bifcl const.bif > g++ -I. -Ilibedit -O -Ilinux-include -c main.cc > g++ -I. -Ilibedit -O -Ilinux-include -c net_util.cc > g++ -I. -Ilibedit -O -Ilinux-include -c util.cc > util.cc: In function `void init_random_seed()': > util.cc:395: `uint32_t' undeclared (first use this function) > util.cc:395: (Each undeclared identifier is reported only once for each > function it appears in.) > util.cc:395: parse error before `[' token > util.cc:399: `buf' undeclared (first use this function) > util.cc:427: parse error before `=' token > util.cc:430: `result' undeclared (first use this function) > make: *** [util.o] Error 1 From yb at sainte-barbe.org Sat Jul 12 12:26:13 2003 From: yb at sainte-barbe.org (Yann Berthier) Date: Sat, 12 Jul 2003 21:26:13 +0200 Subject: Errors compiling bro-pub-0.8a32 on Linux 2.4.20-8 In-Reply-To: <3F103521.6040101@UnixHelpDesk.COM> References: <3F102741.4050003@UnixHelpDesk.COM> <3F103521.6040101@UnixHelpDesk.COM> Message-ID: <20030712192613.GD699@hsc.fr> On Sat, 12 Jul 2003, Christopher Jay Manders wrote: > > I fixed this by adding: > > #include > > to the top of util.cc, since that is where uint32_t is defined on my > Linux.... > > That solved that problem. Then another cropped up in Dict.cc: > > g++ -I. -Ilibedit -O -Ilinux-include -c Dict.cc > Dict.cc: In member function `void* Dictionary::NextEntry(HashKey*&, > IterCookie*&, int) const': > Dict.cc:260: choosing `HashKey::HashKey(const void*, int, unsigned int)' > over ` > HashKey::HashKey(void*, int, int)' > Dict.cc:260: because worst conversion for the former is better than worst > conversion for the latter > Dict.cc:288: choosing `HashKey::HashKey(const void*, int, unsigned int)' > over ` > HashKey::HashKey(void*, int, int)' > Dict.cc:288: because worst conversion for the former is better than worst > conversion for the latter > make: *** [Dict.o] Error 1 > > > This error looks more programatic to fix, so this will take more time. > Anyone with thoughts on this one? Well, i fixed it by doing exactly what the compiler suggests: --- work/bro-pub-0.8a32/Dict.cc Wed Apr 9 08:57:01 2003 +++ /tmp/bro-pub-0.8a32/Dict.cc Thu Jun 26 14:37:51 2003 @@ -257,7 +257,7 @@ entry = (*ttbl[b])[o]; ++cookie->offset; if ( return_hash ) - h = new HashKey(entry->key, entry->len, entry->hash); + h = new HashKey((const void *)entry->key, entry->len, (unsigned int) entry->hash); return entry->value; } @@ -285,7 +285,7 @@ entry = (*ttbl[b])[0]; if ( return_hash ) - h = new HashKey(entry->key, entry->len, entry->hash); + h = new HashKey((const void *) entry->key, entry->len, (unsigned int) entry->hash); cookie->bucket = b; cookie->offset = 1; I have not tried to see if this is programaticaly correct, but with it bro compiles and runs fine for me (FreeBSD 5.1-CURRENT). - yann From jmellander at lbl.gov Sat Jul 12 19:14:59 2003 From: jmellander at lbl.gov (Jim Mellander) Date: Sat, 12 Jul 2003 19:14:59 -0700 Subject: Denial of Service on Bro via Scott Crosby and Dan Wallach's method...fixedin bro-pub-0.8a32? References: <3F1031E6.5080607@UnixHelpDesk.COM> Message-ID: <3F10C0A3.31DA6FA@lbl.gov> Christopher Jay Manders wrote: > > Hi, > > I am interested to do some further testing of this, but does the a32 > release have the fixes for the hashing issue inside? (I am referring to > their paper at: http://www.cs.rice.edu/~scrosby/hash/.) > > Has this been extensively tested? > > Tx! > > Chris if you look in Hash.cc, you'll see the use of MD5 as a hashing function, although the old hashing function can still be used - it certainly is lighter weight & thus retains a performance advantage, less the DOS attack. -- Jim Mellander Incident Response Manager Computer Protection Program Lawrence Berkeley National Laboratory (510) 486-7204 Your fortune for today is: What's so funny? From vern at icir.org Sun Jul 13 12:03:30 2003 From: vern at icir.org (Vern Paxson) Date: Sun, 13 Jul 2003 12:03:30 -0700 Subject: Errors compiling bro-pub-0.8a32 on Linux 2.4.20-8 In-Reply-To: Your message of Sat, 12 Jul 2003 08:20:33 PDT. Message-ID: <200307131903.h6DJ3Uw9074353@jaguar.icir.org> > util.cc:395: `uint32_t' undeclared (first use this function) This is fixed in the next release by changing it to uint32. Vern From vern at icir.org Sun Jul 13 12:02:48 2003 From: vern at icir.org (Vern Paxson) Date: Sun, 13 Jul 2003 12:02:48 -0700 Subject: Bro <-> Snort documentation In-Reply-To: Your message of Fri, 11 Jul 2003 15:34:26 PDT. Message-ID: <200307131902.h6DJ2mw9074294@jaguar.icir.org> > signature kazaa-seen { > ip-proto == tcp > dst-ip == whatever > dst-port == whatever (or omitted, I guess) > payload /.*kazaa regular expression/ > eval function_to_execute_when_kazaa_seen > event "kazaa seen" > } > > > The 'eval' & the 'event' are somewhat confusing. I presume that the > 'signature_match' event is triggered with the string for action, but > when is the 'eval' called (before the event, or after), and with what > args? The function specified by "eval" is called before the signature is determined to have triggered. It's passed in the signature_state just as is signature_match. It returns a boolean, which must be T for the signature to trigger. For an example, see sig.ex.ssl-worm.bro and policy/ssl-worm.bro. Vern From vern at icir.org Sun Jul 13 12:03:42 2003 From: vern at icir.org (Vern Paxson) Date: Sun, 13 Jul 2003 12:03:42 -0700 Subject: Errors compiling bro-pub-0.8a32 on Linux 2.4.20-8 In-Reply-To: Your message of Sat, 12 Jul 2003 09:19:45 PDT. Message-ID: <200307131903.h6DJ3gw9074372@jaguar.icir.org> > Dict.cc: In member function `void* Dictionary::NextEntry(HashKey*&, > IterCookie*&, int) const': > Dict.cc:260: choosing `HashKey::HashKey(const void*, int, unsigned int)' > over ` > HashKey::HashKey(void*, int, int)' > Dict.cc:260: because worst conversion for the former is better than worst > conversion for the latter > Dict.cc:288: choosing `HashKey::HashKey(const void*, int, unsigned int)' > over ` > HashKey::HashKey(void*, int, int)' > Dict.cc:288: because worst conversion for the former is better than worst > conversion for the latter > make: *** [Dict.o] Error 1 > > > This error looks more programatic to fix, so this will take more time. > Anyone with thoughts on this one? Good catch by the compiler - this points out a warning in which two calling sequences with quite different semantics could be confused due to the implicit conversion rules. I've changed the calling sequence of one of the calls to avoid the possible ambiguity. Vern From vern at icir.org Sun Jul 13 12:03:20 2003 From: vern at icir.org (Vern Paxson) Date: Sun, 13 Jul 2003 12:03:20 -0700 Subject: "for and while" in Bro language (and threading?) In-Reply-To: Your message of Sat, 12 Jul 2003 08:33:58 PDT. Message-ID: <200307131903.h6DJ3Kw9074337@jaguar.icir.org> > Either one, or both, would be extremely useful as far as I can see. I > suppose there are reasons that these are not included, and it would be > good to know those reasons. I assume that it is so that someone can't > blow a hole in their foot, since if one doesn't do bounds checks, Bro > would probably freak out. It's not bounds checking, it's the possibility of spending a great deal of time in a single function or event handler, which can lead to packet drops. > It would be nice if the actual bro pieces were threaded for various > reasons. I'd assume that if it were a completely threaded app that the > crashing behavior it seems to exhibit during load, the packet dropping, > and other aspects could be seriously improved. It might help, but it would also introduce a whole set of nasty-to-debug race conditions. I want to avoid those if at all possible. (Note, you can effect a degree of multi-threading by using events for control flow.) > Certainly to split off the BPF code into a spearate thread would > allow it to read on ahead and not loose as much network traffic on a > busy network BPF already runs in a separate thread, namely the kernel, so there's no further gain to be had here. > while the actual parser/analyzers could be chugging along > merrily in another (or other) thread/s. There might indeed be a gain here. It would depend in part on how much data structure locking is required. > Anyone have the reasons that there is no for or while loops? Per the above. > And, what > should be substituted in their place? In what contexts do you find you need them? Vern From vern at icir.org Sun Jul 13 12:03:01 2003 From: vern at icir.org (Vern Paxson) Date: Sun, 13 Jul 2003 12:03:01 -0700 Subject: "for and while" in Bro language In-Reply-To: Your message of Sat, 12 Jul 2003 16:56:48 +0800. Message-ID: <200307131903.h6DJ31w9074312@jaguar.icir.org> > Does Bro have the loop language of "for" or "while" > (like the for and while in C++ language)? It has a for statement that loops over the elements of a set or a table. It doesn't have a loop-while-condition-holds construct. If you find you need one, I'd be interested to hear the partiuclars of what you want to use it for, as I've been trying to avoid adding a general for/while construct (so far, I'm not convinced its uses can't be better served with other language constructs). Vern From vern at icir.org Sun Jul 13 12:03:36 2003 From: vern at icir.org (Vern Paxson) Date: Sun, 13 Jul 2003 12:03:36 -0700 Subject: Errors compiling Bro on OpenBSD 2.9 In-Reply-To: Your message of Sat, 12 Jul 2003 08:25:02 PDT. Message-ID: <200307131903.h6DJ3aw9074364@jaguar.icir.org> > The OpenBSD compile gets the following errors, relating to BIND defines > and such. This is indeed a pain. Note that you can work around it by editing config.h and turning off HAVE_NB_DNS and removing nb_dns.o from OBJ in the Makefile. The autoconf code is supposed to detect this case already, but the test it's using (checking for res_mkquery) isn't powerful enough - it fails on several systems another is Mac OS X). Vern From vern at icir.org Sun Jul 13 12:03:26 2003 From: vern at icir.org (Vern Paxson) Date: Sun, 13 Jul 2003 12:03:26 -0700 Subject: Denial of Service on Bro via Scott Crosby and Dan Wallach's method...fixed in bro-pub-0.8a32? In-Reply-To: Your message of Sat, 12 Jul 2003 09:05:58 PDT. Message-ID: <200307131903.h6DJ3Qw9074345@jaguar.icir.org> > I am interested to do some further testing of this, but does the a32 > release have the fixes for the hashing issue inside? Yes, as indicated in the first item in CHANGES. Vern From vern at icir.org Sun Jul 13 12:59:31 2003 From: vern at icir.org (Vern Paxson) Date: Sun, 13 Jul 2003 12:59:31 -0700 Subject: more syslog? In-Reply-To: Your message of Wed, 25 Jun 2003 15:28:55 EDT. Message-ID: <200307131959.h6DJxVw9077988@jaguar.icir.org> > While I am enjoying running my new bro-0.8_32, I find that some of the > stuff gets reported to syslog (such as ContentGap and some FTP attacks), > while the rest is getting piled to multiple files (ftp.log, http.log, > etc). I looked at the manual and the *.bro file and it looks like its > hard-coded with ALERT statements. Is there any way to globally redirect > everything to syslog? There's no single mechanism for doing this. You should be able to send all the log files to a single location by redef'ing the various log file variables such as ftp_log, etc. For many environments, you wouldn't want to syslog all of it, as it rapidly runs into an immense amount of logging. For finer-grained control over ALERT processing, Robin Sommer has contributed the notion of an event that's generated after ALERT does its processing. (This is in the 0.8a34 release that I just announced.) It looks like: event alert_action(a: alert_info, action: AlertAction) Because it's parameterized with the corresponding action, you can then incorporate the action into your decision about what to do with the alert. ALERT still generates a syslog for loggable actions, and prints the alert to the alert log; perhaps it shouldn't, I'm undecided at this point. Looking down the road, Umesh Shankar has implemented a "match" facility that will provide more powerful event filtering & action designation. I haven't integrated his changes yet, but will soon - I finally have dug out for a bit and have some time for Bro development. Vern From vern at icir.org Sun Jul 13 12:59:57 2003 From: vern at icir.org (Vern Paxson) Date: Sun, 13 Jul 2003 12:59:57 -0700 Subject: A patch for Bro in OpenBSD In-Reply-To: Your message of Thu, 26 Jun 2003 15:22:20 +0200. Message-ID: <200307131959.h6DJxvw9078004@jaguar.icir.org> > I've got warning during execution too : > > | ./bro: ./bro : WARNING: symbol(__p_class_syms) size mismatch relink your program > | ./bro: ./bro : WARNING: symbol(__p_type_syms) size mismatch relink your program Let me know if you still have this problem with the new 0.8a34 release. Did you get the BIND dependencies worked out for OpenBSD? Vern From bmc at snort.org Sun Jul 13 17:08:29 2003 From: bmc at snort.org (Brian) Date: Sun, 13 Jul 2003 20:08:29 -0400 Subject: "for and while" in Bro language (and threading?) In-Reply-To: <200307131903.h6DJ3Kw9074337@jaguar.icir.org> References: <200307131903.h6DJ3Kw9074337@jaguar.icir.org> Message-ID: <20030714000829.GA5934@sourcefire.com> On Sun, Jul 13, 2003 at 12:03:20PM -0700, Vern Paxson wrote: > In what contexts do you find you need them? A good example of the need for while loops is doing integer overflow detection in RPC services. To do it properly, you need to be able to check the length of each argument in the call (or response, since clients can be vulnerable as well...) -brian From vern at icir.org Mon Jul 14 02:28:04 2003 From: vern at icir.org (Vern Paxson) Date: Mon, 14 Jul 2003 02:28:04 -0700 Subject: "for and while" in Bro language (and threading?) In-Reply-To: Your message of Sun, 13 Jul 2003 20:08:29 EDT. Message-ID: <200307140928.h6E9S4w9084078@jaguar.icir.org> > A good example of the need for while loops is doing integer overflow > detection in RPC services. To do it properly, you need to be able to > check the length of each argument in the call (or response, since clients > can be vulnerable as well...) If Bro provided the arguments in generic form to the policy script (it doesn't currently, it instead provides parsed versions) then it would be as a table - so the existing "for" operator would serve for iterating through them. I'm pushing back here because I want to understand if there's a compelling need to add this language feature. I think for many uses, the existing features will serve. That said, I expect there *are* such cases where a more general loop construct is needed. But I want to better understand where those are needed, because it's not clear that C-style "while" or "for" will be the best way for them. There are other paradigms. For example, S has very powerful array-oriented operators, such that it's quite rare you ever need to write a for or while loop. Vern From Chris.Manders at UnixHelpDesk.COM Mon Jul 14 06:04:32 2003 From: Chris.Manders at UnixHelpDesk.COM (Christopher Jay Manders) Date: Mon, 14 Jul 2003 06:04:32 -0700 Subject: Denial of Service on Bro via Scott Crosby and Dan Wallach's method...fixed in bro-pub-0.8a32? In-Reply-To: <200307131903.h6DJ3Qw9074345@jaguar.icir.org> References: <200307131903.h6DJ3Qw9074345@jaguar.icir.org> Message-ID: <3F12AA60.30503@UnixHelpDesk.COM> Thanks! With all of the other files in the same base directory, I usually end up cleaning the *.h, *.cc, *.c *.y *.l ... source files into a new directory called (like ./src/) in order to see anything new as far as docs and files go. This might be a good thing to do by default, since it allows one to see the other things besides the source and seems a bit clearer organization. Just a suggestion for the future. There are some good changes, I note. Thanks for pointing this out. Cheers! Chris >>I am interested to do some further testing of this, but does the a32 >>release have the fixes for the hashing issue inside? > > > Yes, as indicated in the first item in CHANGES. > > Vern From Chris.Manders at UnixHelpDesk.COM Mon Jul 14 06:18:50 2003 From: Chris.Manders at UnixHelpDesk.COM (Christopher Jay Manders) Date: Mon, 14 Jul 2003 06:18:50 -0700 Subject: Errors compiling bro-pub-0.8a32 on Linux 2.4.20-8 In-Reply-To: <200307131903.h6DJ3gw9074372@jaguar.icir.org> References: <200307131903.h6DJ3gw9074372@jaguar.icir.org> Message-ID: <3F12ADBA.20302@UnixHelpDesk.COM> >>Dict.cc: In member function `void* Dictionary::NextEntry(HashKey*&, >> IterCookie*&, int) const': >>Dict.cc:260: choosing `HashKey::HashKey(const void*, int, unsigned int)' >>over ` >> HashKey::HashKey(void*, int, int)' >>Dict.cc:260: because worst conversion for the former is better than worst >> conversion for the latter >>Dict.cc:288: choosing `HashKey::HashKey(const void*, int, unsigned int)' >>over ` >> HashKey::HashKey(void*, int, int)' >>Dict.cc:288: because worst conversion for the former is better than worst >> conversion for the latter >>make: *** [Dict.o] Error 1 >> >> >>This error looks more programatic to fix, so this will take more time. >>Anyone with thoughts on this one? > > > Good catch by the compiler - this points out a warning in which two > calling sequences with quite different semantics could be confused due > to the implicit conversion rules. > > I've changed the calling sequence of one of the calls to avoid the > possible ambiguity. It looks like the main thing that you changed was the class definition in Hash.h (at least for this). That seems better than hardcoding the suggestion of casting each entry-> reference to make it fit one of the overloaded HashKey::HashKey functions. One has to assume the right one to cast the args towards it. FYI: the last problem with the build on Linux is the same as for OpenBSD with the HAVE_NB_DNS. You are right that undefining that and getting rid of the nb_dns.o in the OBJ section of the Makefile seem to have the build working. This works with Linux as well. There must be a better way of using res_mkquery to assure that this calls in the nb_dns.c will work s expected. I do note that nb_dns.h does not even exist on my Linux box, but res_mkquery calls work if I use the and includes. The same is true on OpenBSD, BTW. Cheers! Chris From vern at icir.org Mon Jul 14 06:46:24 2003 From: vern at icir.org (Vern Paxson) Date: Mon, 14 Jul 2003 06:46:24 -0700 Subject: Errors compiling bro-pub-0.8a32 on Linux 2.4.20-8 In-Reply-To: Your message of Mon, 14 Jul 2003 06:18:50 PDT. Message-ID: <200307141346.h6EDkOw9086987@jaguar.icir.org> > There must be a better way of using res_mkquery to assure that this > calls in the nb_dns.c will work s expected. I've asked Craig Leres (who wrote the nb_dns stuff, and is one of Bro's autoconf maintainers) to look into this. > I do note that nb_dns.h does > not even exist on my Linux box That's a Bro source file rather than a system file, so checking for it won't help. Vern From jmellander at lbl.gov Mon Jul 14 09:14:35 2003 From: jmellander at lbl.gov (Jim Mellander) Date: Mon, 14 Jul 2003 09:14:35 -0700 Subject: Denial of Service on Bro via Scott Crosby and Dan Wallach's method...fixedin bro-pub-0.8a32? References: <3F1031E6.5080607@UnixHelpDesk.COM> <3F10C0A3.31DA6FA@lbl.gov> Message-ID: <3F12D6EB.B6E99F9B@lbl.gov> Jim Mellander wrote: > > Christopher Jay Manders wrote: > > > > Hi, > > > > I am interested to do some further testing of this, but does the a32 > > release have the fixes for the hashing issue inside? (I am referring to > > their paper at: http://www.cs.rice.edu/~scrosby/hash/.) > > > > Has this been extensively tested? > > > > Tx! > > > > Chris > > if you look in Hash.cc, you'll see the use of MD5 as a hashing function, > although the old hashing function can still be used - it certainly is > lighter weight & thus retains a performance advantage, less the DOS > attack. > By the way, it seems to me that the use of MD5 as a hash function is overkill. As I understand it, the issue is not the hash function, per se, but the predictability of the hashing function potentially leading to excessive chaining by the insertion of crafted packets, and thus degrading the hashing function to a linear search. MD5, of course, makes it computationally infeasable to develop this chaining, but I would argue that a lighter weight solution would also give good results, to wit: Since the issue is the predictability of the hash, the problem really boils down to determing a way to increase the unpredictability. One method would be to introduce a reproducable random factor, that varies each run of Bro. So, on startup of Bro, precompute a 2^n size table of random numbers derived from /dev/random, or other non-reproducable source. Then the hashing function could select n bits from the hashed value (using the original hash function), lookup the table & xor the value with the computed hash. The chaining problem still exists, of course, but what is removed is the predictability, since the table (& thus the hash function) is specific to *that* run of bro. Any comments? -- Jim Mellander Incident Response Manager Computer Protection Program Lawrence Berkeley National Laboratory (510) 486-7204 Your fortune for today is: She has an alarm clock and a phone that don't ring -- they applaud. From rpang at CS.Princeton.EDU Mon Jul 14 09:46:32 2003 From: rpang at CS.Princeton.EDU (Ruoming Pang) Date: Mon, 14 Jul 2003 12:46:32 -0400 (EDT) Subject: Denial of Service on Bro via Scott Crosby and Dan Wallach's method...fixedin bro-pub-0.8a32? In-Reply-To: <3F12D6EB.B6E99F9B@lbl.gov> References: <3F1031E6.5080607@UnixHelpDesk.COM> <3F10C0A3.31DA6FA@lbl.gov> <3F12D6EB.B6E99F9B@lbl.gov> Message-ID: > but I would argue that a lighter weight solution would also give good > results, to wit: > > Since the issue is the predictability of the hash, the problem really > boils down to determing a way to increase the unpredictability. One > method would be to introduce a reproducable random factor, that varies > each run of Bro. > > So, on startup of Bro, precompute a 2^n size table of random numbers > derived from /dev/random, or other non-reproducable source. Then the > hashing function could select n bits from the hashed value (using the > original hash function), lookup the table & xor the value with the > computed hash. The chaining problem still exists, of course, but what > is removed is the predictability, since the table (& thus the hash > function) is specific to *that* run of bro. > > Any comments? Jim, Thanks for your suggestion. Yes, we are looking for an implementation of a *universal* hash function (e.g. one option is to find a stable implementation of UMAC). I'd love to hear if you have any suggestion on this regard. As to the hash function you suggested, I think it would suffer the same kind of DoS attack. Scott's paper explains it quite well -- the problem with the original function is that it first reduces the value down to a 32-bit value with a simple function, and it is easy to find collisions for this step so that the attacker can generate numerous strings that will be reduced to the same 32-bit number. Afterwards, no matter what you do on the 32-bit number can prevent collisions. Ruoming From jmellander at lbl.gov Mon Jul 14 09:54:36 2003 From: jmellander at lbl.gov (Jim Mellander) Date: Mon, 14 Jul 2003 09:54:36 -0700 Subject: Denial of Service on Bro via Scott Crosby and Dan Wallach's method...fixedin bro-pub-0.8a32? References: <3F1031E6.5080607@UnixHelpDesk.COM> <3F10C0A3.31DA6FA@lbl.gov> <3F12D6EB.B6E99F9B@lbl.gov> Message-ID: <3F12E04C.329A6A56@lbl.gov> Ruoming Pang wrote: > > > Jim, > > Thanks for your suggestion. Yes, we are looking for an implementation of a > *universal* hash function (e.g. one option is to find a stable > implementation of UMAC). I'd love to hear if you have any suggestion on > this regard. > > As to the hash function you suggested, I think it would suffer the same > kind of DoS attack. Scott's paper explains it quite well -- the problem > with the original function is that it first reduces the value down to a > 32-bit value with a simple function, and it is easy to find collisions for > this step so that the attacker can generate numerous strings that will be > reduced to the same 32-bit number. Afterwards, no matter what you do on > the 32-bit number can prevent collisions. > > Ruoming Hmm, thats a good point - the reduction to a 32-bit number would still be predictable. Why not apply the xor function to the input, then, before the reduction takes place? - this presumably would remove the predictability of the reduction step. -- Jim Mellander Incident Response Manager Computer Protection Program Lawrence Berkeley National Laboratory (510) 486-7204 Your fortune for today is: Save energy: Drive a smaller shell. From jhlee2 at csl.hanyang.ac.kr Fri Jul 18 05:55:04 2003 From: jhlee2 at csl.hanyang.ac.kr (=?ks_c_5601-1987?B?wMzB9sjG?=) Date: Fri, 18 Jul 2003 21:55:04 +0900 Subject: Two Questions about Bro Message-ID: <001501c34d2b$cf3ade20$102e68a6@cslab.hanyang.ac.kr> Hi, My name is Ji-Hoon, Lee and nice to meet you all I have an interest in detecting network threats and measuring the loss of bandwidth caused by them. So, I choose the Bro to detect them. I've read manual and installed Bro to my FreeBSD. It works good!! and I also ran Tcpdump to record all packets on my local network for one day. Today I put tcpdump file to the Bro to analysis with mt.bro policy file. Bro returns many weird logs and works good. but when I put with mt.bro and worm.bro policy files. It makes segmentation fault. Worm analyzer doesn't work perfect now ? and I have one more question. I want to add another virus/worm detection feature to Bro. (Likes Klez or Lovegate) But Manual is hard for me to do that job so I'm looking for information that can help me. Where can I find it ? Thank to reading my poor writing (Sometimes I think I have to study English first of all --") and hope you all have a nice weekend. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20030718/ff65eb34/attachment.html From vern at icir.org Mon Jul 21 23:24:26 2003 From: vern at icir.org (Vern Paxson) Date: Mon, 21 Jul 2003 23:24:26 -0700 Subject: Two Questions about Bro In-Reply-To: Your message of Fri, 18 Jul 2003 21:55:04 +0900. Message-ID: <200307220624.h6M6OQw9036541@jaguar.icir.org> > but when I put with mt.bro and worm.bro policy files. It makes segmentation > fault. Worm analyzer doesn't work perfect now ? You need to provide details and, if at all possible, a test case that reproduces the problem. You should probably send these to me privately rather than via the mailing list, unless others on the list indicate that they've encountered a similar problem. > and I have one more question. I want to add another virus/worm detection > feature to Bro. (Likes Klez or Lovegate) It would be best to do this using Bro's new signature engine. Currently, worm.bro is only for detecting HTTP-based worms. > But Manual is hard for me to do that job so I'm looking for information > that can help me. Where can I find it ? Unfortunately, it will be just as difficult, or more so, to explain how to do this via email as for you to learn how to do so from the manual plus inspecting the policy scripts that come with the Bro distribution. Vern From hxin at anr.mcnc.org Tue Jul 22 13:04:25 2003 From: hxin at anr.mcnc.org (Hongjie Xin) Date: Tue, 22 Jul 2003 16:04:25 -0400 Subject: Need help! Link failed during compile 0.8a34 version Message-ID: <3F1D98C9.8020507@anr.mcnc.org> Hi, I am new here. I tried to get whole archive from majordomo for previous mailing messages and looks like I am still waiting. I was trying to compile the package under redhat 9.0. I got the following error message in last link sentence. I still got the same error even after I upgraded the bind to latest redhat update (glibc-2.3.2-27.9). nb_dns.o(.text+0x62d): In function `nb_dns_activity': : undefined reference to `__ns_initparse' nb_dns.o(.text+0x6f2): In function `nb_dns_activity': : undefined reference to `_ns_flagdata' nb_dns.o(.text+0x6f8): In function `nb_dns_activity': : undefined reference to `_ns_flagdata' nb_dns.o(.text+0x870): In function `nb_dns_activity': : undefined reference to `__ns_parserr' collect2: ld returned 1 Could anyone help me? Thanks! Hongjie -- ----------------------------------- Hongjie Xin Ph#: (919)248-1409 Network Research Engineer, FAX#:(919)248-1455 Advanced Network Research Group, MCNC-RDI hxin at anr.mcnc.org From sommer at in.tum.de Tue Jul 22 14:11:12 2003 From: sommer at in.tum.de (Robin Sommer) Date: Tue, 22 Jul 2003 23:11:12 +0200 Subject: Need help! Link failed during compile 0.8a34 version In-Reply-To: <3F1D98C9.8020507@anr.mcnc.org> References: <3F1D98C9.8020507@anr.mcnc.org> Message-ID: <20030722211112.GA21535@net.informatik.tu-muenchen.de> On Tue, Jul 22, 2003 at 16:04 -0400, Hongjie Xin wrote: > I was trying to compile the package under redhat 9.0. Please try the attached patch. It works at least for Debian-based systems. Robin P.S.: If anyone happens to know enough about autoconf to include this into configure.ac, it would be a nice thing to add. -- Robin Sommer * Room 01.08.055 * www.net.in.tum.de TU Munich * Phone (089) 289-18006 * sommer at in.tum.de -------------- next part -------------- /usr/bin/cvs diff -u Makefile.in Index: Makefile.in =================================================================== RCS file: /home/cvs/repository/bro/Makefile.in,v retrieving revision 1.48 diff -u -u -r1.48 Makefile.in --- Makefile.in 18 Jul 2003 07:25:02 -0000 1.48 +++ Makefile.in 22 Jul 2003 21:02:15 -0000 @@ -49,7 +49,7 @@ LIBEDIT_LIBS = -Llibedit -ltermcap -ledit LFLAGS = -s -LIBS = $(LIBEDIT_LIBS) @LIBS@ -lm +LIBS = $(LIBEDIT_LIBS) @LIBS@ -lm /usr/lib/libresolv.a # Purify barfs when c++ is used for $(CPLUS). PURIFY_CPLUS = g++ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20030722/ff5cbc6c/attachment.bin From hxin at anr.mcnc.org Tue Jul 22 14:19:21 2003 From: hxin at anr.mcnc.org (Hongjie Xin) Date: Tue, 22 Jul 2003 17:19:21 -0400 Subject: Need help! Link failed during compile 0.8a34 version In-Reply-To: <20030722211112.GA21535@net.informatik.tu-muenchen.de> References: <3F1D98C9.8020507@anr.mcnc.org> <20030722211112.GA21535@net.informatik.tu-muenchen.de> Message-ID: <3F1DAA59.2010702@anr.mcnc.org> Appreciate. It works. Meanwhile I searched something from google newsgroup. It may explain the reason. # nm /usr/lib/libresolv.a | sed "s/[^ ]* //" |sort > a # nm /usr/lib/libresolv.so | sed "s/[^ ]* //" |sort > so # diff a so |grep __ns_initparse < T __ns_initparse > t __ns_initparse < U __ns_initparse From 'info nm', lowercase t means local, uppercase T means global That's different among libresolv.a and libresolv.so. No idea why glibc leaves such arrangement. Hongjie Robin Sommer wrote: > On Tue, Jul 22, 2003 at 16:04 -0400, Hongjie Xin wrote: > > >>I was trying to compile the package under redhat 9.0. > > > Please try the attached patch. It works at least for Debian-based > systems. > > Robin > > P.S.: If anyone happens to know enough about autoconf to include > this into configure.ac, it would be a nice thing to add. > > > > ------------------------------------------------------------------------ > > /usr/bin/cvs diff -u Makefile.in > Index: Makefile.in > =================================================================== > RCS file: /home/cvs/repository/bro/Makefile.in,v > retrieving revision 1.48 > diff -u -u -r1.48 Makefile.in > --- Makefile.in 18 Jul 2003 07:25:02 -0000 1.48 > +++ Makefile.in 22 Jul 2003 21:02:15 -0000 > @@ -49,7 +49,7 @@ > LIBEDIT_LIBS = -Llibedit -ltermcap -ledit > > LFLAGS = -s > -LIBS = $(LIBEDIT_LIBS) @LIBS@ -lm > +LIBS = $(LIBEDIT_LIBS) @LIBS@ -lm /usr/lib/libresolv.a > > # Purify barfs when c++ is used for $(CPLUS). > PURIFY_CPLUS = g++ -- ----------------------------------- Hongjie Xin Ph#: (919)248-1409 Network Research Engineer, FAX#:(919)248-1455 Advanced Network Research Group, MCNC-RDI hxin at anr.mcnc.org From christian at whoop.org Wed Jul 23 07:31:43 2003 From: christian at whoop.org (Christian Kreibich) Date: 23 Jul 2003 15:31:43 +0100 Subject: Need help! Link failed during compile 0.8a34 version In-Reply-To: <20030722211112.GA21535@net.informatik.tu-muenchen.de> References: <3F1D98C9.8020507@anr.mcnc.org> <20030722211112.GA21535@net.informatik.tu-muenchen.de> Message-ID: <1058970703.2177.133.camel@ghouls.cl.cam.ac.uk> Hi all, On Tue, 2003-07-22 at 22:11, Robin Sommer wrote: > On Tue, Jul 22, 2003 at 16:04 -0400, Hongjie Xin wrote: > > > I was trying to compile the package under redhat 9.0. > > Please try the attached patch. It works at least for Debian-based > systems. here's an attempt of a configure check for this; it works for my RH9. Open questions: - what to do if workaround test fails - whether to test for other locations of libresolv.a Let me know if it works for you -- I'm far from an autoconf expert. In particular, I don't know if it'll work with other autoconf versions (that's always where the fun starts ...). Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org -------------- next part -------------- --- configure.ac Sun Jul 13 20:18:23 2003 +++ configure.ac.new Wed Jul 23 15:26:40 2003 @@ -102,6 +102,24 @@ AC_CHECK_FUNCS(strerror) AC_REPLACE_FUNCS(strsep) +dnl Check if ns_initparse and friends do work with -lresolv +AC_CHECK_LIB(resolv, ns_initparse, bro_ns_foo_works=yes) +if test "x$bro_ns_foo_works" = x; then + dnl Didn't work -- need to check manually if workaround works better + AC_MSG_CHECKING([for ns_initparse in /usr/lib/libresolv.a]) + saved_libs="${LIBS}" + LIBS="${LIBS} /usr/lib/libresolv.a" + AC_LINK_IFELSE(AC_LANG_PROGRAM([[#include ]], [[ns_initparse(0,0,0);]]), bro_ns_foo_static_works=yes) + + if test "x$bro_ns_foo_static_works" = x; then + LIBS="${saved_libs}" + AC_MSG_RESULT(no) + else + AC_MSG_RESULT(yes) + fi +fi + + AC_DEFINE(HAVE_READLINE,,[hacked version of libedit]) dnl From sommer at in.tum.de Thu Jul 24 01:31:11 2003 From: sommer at in.tum.de (Robin Sommer) Date: Thu, 24 Jul 2003 10:31:11 +0200 Subject: Need help! Link failed during compile 0.8a34 version In-Reply-To: <1058970703.2177.133.camel@ghouls.cl.cam.ac.uk> References: <3F1D98C9.8020507@anr.mcnc.org> <20030722211112.GA21535@net.informatik.tu-muenchen.de> <1058970703.2177.133.camel@ghouls.cl.cam.ac.uk> Message-ID: <20030724083111.GA3240@net.informatik.tu-muenchen.de> On Wed, Jul 23, 2003 at 15:31 +0100, Christian Kreibich wrote: > Let me know if it works for you -- I'm far from an autoconf expert. In Works fine on Debian, too (and also on Solaris and FreeBSD which don't need the work-around). Thanks! Robin -- Robin Sommer * Room 01.08.055 * www.net.in.tum.de TU Munich * Phone (089) 289-18006 * sommer at in.tum.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20030724/ed8d78a5/attachment.bin