From zhangwei at comexgenesys.com Thu Jul 1 20:10:08 2004 From: zhangwei at comexgenesys.com (Cliff) Date: Fri, 2 Jul 2004 11:10:08 +0800 Subject: bro's framwork Message-ID: <001601c45fe2$1b4c0130$7a0aa8c0@comex10> Hi guys, Whether are there people to research the code and the bro's framwork.Or how should i start the study of bro' development. Thanks, Cliff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20040702/079efe86/attachment.html From rmkml at wanadoo.fr Sat Jul 3 05:20:28 2004 From: rmkml at wanadoo.fr ( Hi, I receive this packet : 13:59:42.305909 62.46.161.181 > 21.3.4.16: ip 48 (ttl 117, id 28092, len 68) tethereal convert : 2 13:59:42.305909 62.46.161.181 -> 21.3.4.16 IP IPv6 hop-by-hop option (0x00) Bro not event this, possible configure bro for detect this ? Regards Rmkml at Wanadoo.fr PS: Prelude event this. From plucs at bigpond.net.au Tue Jul 6 17:07:31 2004 From: plucs at bigpond.net.au (plucs at bigpond.net.au) Date: Wed, 07 Jul 2004 10:07:31 +1000 Subject: No subject Message-ID: <139158139163.139163139158@email.bigpond.com> get bro archive From vern at icir.org Wed Jul 7 18:51:05 2004 From: vern at icir.org (Vern Paxson) Date: Wed, 07 Jul 2004 18:51:05 -0700 Subject: [Bro] Detect ip proto 48 [ipv6] ? In-Reply-To: Your message of Sat, 03 Jul 2004 14:20:28 +0200. Message-ID: <200407080151.i681p5De014505@jaguar.icir.org> > 2 13:59:42.305909 62.46.161.181 -> 21.3.4.16 IP IPv6 hop-by-hop > option (0x00) > > Bro not event this, Correct. Bro's IPv6 support doesn't currently support IPv6 options (either hop-by-hop or end-to-end). If someone wants to contribute that, that would be great. For LBL, it's currently not a high priority, so will likely take a while to be addressed. Vern From vern at icir.org Wed Jul 7 18:51:02 2004 From: vern at icir.org (Vern Paxson) Date: Wed, 07 Jul 2004 18:51:02 -0700 Subject: [Bro] add _ in "bad option termination" file : weird.log In-Reply-To: Your message of Wed, 30 Jun 2004 01:09:19 +0200. Message-ID: <200407080151.i681p2De014497@jaguar.icir.org> > I found this new event : > > bad option termination > > in weird.log > > but this event not contains "_" ? > > Possible change to : ? > > bad_option_termination The whole "weird" framework needs reworking, similar to what's been done for alerts. Given that (and because there are many such glitches), I'm not inclined to fix minor glitches like the above for now. Vern From christian at whoop.org Fri Jul 9 11:34:05 2004 From: christian at whoop.org (Christian Kreibich) Date: Fri, 09 Jul 2004 11:34:05 -0700 Subject: Question about Val serialization Message-ID: <1089398045.10880.39.camel@localhost.localdomain> Master Robin, I have a question about the serialization of vals (when serializing an event call, for example). A bit of background: yesterday looked at support for sending/receiving records in Broccoli. I got receiving records working fairly quickly, and noticed that the serialization protocol currently insists on sending the full serialized type of the val it is sending (RemoteSerializer.cc, around 126): loop_over_list(*args, i) (*args)[i]->Serialize(this, true, info); ^^^^ calling bool Val::Serialize(Serializer* s, bool save_type, const SerialInfo& info) const; My question is, why is it necessary to send the full type details along with the val, and not just an identifier of the type? It seems to me that since types aren't really first-class data structures in the Bro language (ie. no reflection etc) the remote Bro won't be able to do much with the val if the script doesn't know the type already anyway? I know the serialization caching mechanism you're using to stop sending types repeatedly, but why is it *ever* necessary to send a type? Clearly you had a reason in mind ... I'm of course asking because ideally in Broccoli I'd like to be able to send a record val just by saying what type of record it is and then just send the list of values stored in the record. So, is there any chance that sending the type along will be optional in the new serialization protocol? Thanks, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From christian at whoop.org Fri Jul 9 18:31:46 2004 From: christian at whoop.org (Christian Kreibich) Date: Fri, 09 Jul 2004 18:31:46 -0700 Subject: compile problems on Mac OS X (with XCode 1.2 and BIND9) In-Reply-To: References: Message-ID: <1089423105.10880.403.camel@localhost.localdomain> Hi, I looked into this today ... thank Brian for prodding me -- you owe me a beer because fixing this was painful and nobody has donated a powerbook so far :) On Mon, 2004-06-21 at 13:30, Ruoming Pang wrote: > I am trying to compile Bro on a Mac OS X and encounter the following > two problems, both related to nb_dns.c: > > The first is compile error. It is because the header file > arpa/nameser.h does not define HEADER, which is defined in > arpa/nameser_compat.h. nameser_compat.h will be included by nameser.h > only if BIND_8_COMPAT is defined, but I don't know if we should define > that. After including nameser_compat.h in nb_dns.c, it is able to > compile correctly. [snip] > Next came the link error: > > ld: Undefined symbols: > _res_9_dn_expand > _res_9_init > _res_9_mkquery > _res_9_ns_initparse > _res_9_ns_msg_getflag > _res_9_ns_parserr > > This is because libresolv is not linked. Looking at the configure > script reveals that it looks for libresolv.a, but only libresolv.dylib > is available. Just adding '-lresolv' to Makefile solves the problem. Okay ... well what I see here is that if BIND_8_COMPAT is defined, nameser8_compat.h is included (note the "8"), and that causes nonblocking lookups to be disabled because nameser8_compat does not define ns_msg. What I'm doing in the attached patch is 1. check whether you're running Darwin 2. if so, test whether just including arpa/nameser.h gives you HEADER 3. if 2 fails, include arpa/nameser_compat.h and use -lresolv instead of /usr/lib/libresolv.a Just using -lresolv in general bombs on at least Linux. *sigh*. Build tested on Darwin, Linux, FreeBSD. Apply with -p1. The patch also contains a few comments for configure.ac, and removes duplicated ones for OpenSSL checks. Fingers crossed, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org -------------- next part -------------- --- bro-pub-0.9a2/configure.ac 2004-05-24 13:13:57.000000000 -0700 +++ /home/cpk25/devel/bro-pub-0.9a2/configure.ac 2004-07-09 18:21:32.000000000 -0700 @@ -55,7 +55,10 @@ AC_LBL_ENABLE_CHECK(brov6 activemapping expire-dfa-states mpatrol debug openssl) -# Check for OpenSSL >= 0.9.7 +dnl ################################################ +dnl # OpenSSL +dnl ################################################ + if test "$use_openssl" != "No"; then saved_libs="${LIBS}" AC_CHECK_LIB(crypto, OPENSSL_add_all_algorithms_conf, @@ -68,7 +71,6 @@ LIBS="${saved_libs}" fi -# Check that we have indeed >= 0.9.7 headers. if test "$use_openssl" != "No"; then saved_cflags="${CFLAGS}" CFLAGS="${CFLAGS} -I${OPENSSL}/include" @@ -98,7 +100,7 @@ ) fi -# Check for OpenSSL >= 0.9.7 +# Check for version >= 0.9.7 if test "$use_openssl" = "Yes"; then saved_libs="${LIBS}" LIBS="${LIBS} -lssl -lcrypto" @@ -118,9 +120,30 @@ else AC_SUBST(WANT_SSL_OBJ, "") fi + +dnl ################################################ +dnl # OS-specific hacks and tweaks +dnl ################################################ + +dnl Specifying a specific resolver library seems to work/be necessary +dnl on all OSs, but Darwin needs -lresolv instead of /usr/lib/libresolv.a +dnl We define the default here and overwrite below. --ck +bro_libresolv="/usr/lib/libresolv.a" case "$target_os" in +darwin*) + AC_MSG_CHECKING([if we need to include arpa/nameser_compat.h]) + AC_COMPILE_IFELSE(AC_LANG_PROGRAM([[#include ]], [[HEADER *hdr;]]), bro_ns_header_defined=yes) + if test "z$bro_ns_header_defined" = x; then + AC_MSG_RESULT(no) + else + AC_DEFINE(NEED_NAMESER_COMPAT_H,,[Compatibility for Darwin]) + bro_libresolv="-lresolv" + AC_MSG_RESULT(yes) + fi + ;; + linux*) AC_MSG_CHECKING(Linux kernel version) AC_CACHE_VAL(ac_cv_linux_vers, @@ -134,7 +157,9 @@ esac -dnl Checks for programs. +dnl ################################################ +dnl # Checks for programs +dnl ################################################ AC_PROG_YACC AC_PROG_CXX AC_PROG_LEX @@ -158,7 +183,9 @@ esac -dnl Checks for header files. +dnl ################################################ +dnl # Checks for header files. +dnl ################################################ AC_HEADER_STDC AC_LBL_TYPE_SIGNAL AC_LBL_CHECK_TYPE(int32_t, int) @@ -196,7 +223,9 @@ AC_BRO_SYSLOG_INT AC_BRO_SOCK_DECL -dnl Checks for library functions. +dnl ################################################ +dnl # Checks for library functions. +dnl ################################################ AC_LBL_LIBPCAP(V_PCAPDEP, V_INCLS) AC_CHECK_FUNCS(bpf_set_bufsize) AC_FUNC_MEMCMP @@ -209,9 +238,9 @@ 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]) + AC_MSG_CHECKING([for ns_initparse in resolver]) saved_libs="${LIBS}" - LIBS="${LIBS} /usr/lib/libresolv.a" + LIBS="${LIBS} $bro_libresolv" 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 --- bro-pub-0.9a2/nb_dns.c 2003-03-25 19:47:43.000000000 -0800 +++ /home/cpk25/devel/bro-pub-0.9a2/nb_dns.c 2004-07-09 17:57:53.000000000 -0700 @@ -41,6 +41,9 @@ #include #include +#ifdef NEED_NAMESER_COMPAT_H +#include +#endif #include #ifdef HAVE_MEMORY_H From rpang at CS.Princeton.EDU Fri Jul 9 21:14:55 2004 From: rpang at CS.Princeton.EDU (Ruoming Pang) Date: Sat, 10 Jul 2004 00:14:55 -0400 Subject: compile problems on Mac OS X (with XCode 1.2 and BIND9) In-Reply-To: <1089423105.10880.403.camel@localhost.localdomain> References: <1089423105.10880.403.camel@localhost.localdomain> Message-ID: Christian, Thanks for looking into it. > you owe me a beer because .... Sure. :) > Okay ... well what I see here is that if BIND_8_COMPAT is defined, > nameser8_compat.h is included (note the "8"), and that causes > nonblocking lookups to be disabled because nameser8_compat does not > define ns_msg. > > What I'm doing in the attached patch is > > 1. check whether you're running Darwin > 2. if so, test whether just including arpa/nameser.h gives you HEADER > 3. if 2 fails, include arpa/nameser_compat.h and use -lresolv instead > of > /usr/lib/libresolv.a > > Just using -lresolv in general bombs on at least Linux. *sigh*. > > Build tested on Darwin, Linux, FreeBSD. Apply with -p1. The patch also > contains a few comments for configure.ac, and removes duplicated ones > for OpenSSL checks. I'm wondering if the problem is due to BIND 9 rather than Darwin. Just a random, unverified thought, as I haven't tried it on any other system that has BIND 9. But the FreeBSD on jaguar doesn't have BIND 9. Ruoming From dmoore at ucsd.edu Fri Jul 9 23:10:38 2004 From: dmoore at ucsd.edu (David Moore) Date: Fri, 09 Jul 2004 23:10:38 -0700 Subject: [Bro] Detect ip proto 48 [ipv6] ? In-Reply-To: <200407080151.i681p5De014505@jaguar.icir.org> (Vern Paxson's message of "Wed, 07 Jul 2004 18:51:05 -0700") References: <200407080151.i681p5De014505@jaguar.icir.org> Message-ID: Vern Paxson writes: >> 2 13:59:42.305909 62.46.161.181 -> 21.3.4.16 IP IPv6 hop-by-hop >> option (0x00) >> >> Bro not event this, > > Correct. Bro's IPv6 support doesn't currently support IPv6 options (either > hop-by-hop or end-to-end). If someone wants to contribute that, that would > be great. For LBL, it's currently not a high priority, so will likely take > a while to be addressed. Why is there an IPv6 option protocol number appearing in an IPv4 packet? Maybe it's just a bad packet. -- david From vern at icir.org Fri Jul 9 23:27:24 2004 From: vern at icir.org (Vern Paxson) Date: Fri, 09 Jul 2004 23:27:24 -0700 Subject: [Bro] Detect ip proto 48 [ipv6] ? In-Reply-To: Your message of Fri, 09 Jul 2004 23:10:38 PDT. Message-ID: <200407100627.i6A6RODe030084@jaguar.icir.org> > Why is there an IPv6 option protocol number appearing in an IPv4 packet? > Maybe it's just a bad packet. Perhaps it's an IPv6 packet that has IPv4-embedded addresses, which is why tcpdump prints IPv4 addresses rather than IPv6? I wouldn't think tcpdump's printer could even try to find the presence of an IPv6 hop-by-hop option in a true IPv4 packet. Vern From christian at whoop.org Sat Jul 10 01:28:59 2004 From: christian at whoop.org (Christian Kreibich) Date: Sat, 10 Jul 2004 01:28:59 -0700 Subject: compile problems on Mac OS X (with XCode 1.2 and BIND9) In-Reply-To: References: <1089423105.10880.403.camel@localhost.localdomain> Message-ID: <1089448139.10882.407.camel@localhost.localdomain> Hi! On Fri, 2004-07-09 at 21:14, Ruoming Pang wrote: > > I'm wondering if the problem is due to BIND 9 rather than Darwin. Just > a random, unverified thought, as I haven't tried it on any other system > that has BIND 9. But the FreeBSD on jaguar doesn't have BIND 9. Yeah it might very well just be a bind issue -- in that case the check should simply be moved from being darwin-specific to general. Frankly I don't understand this stuff. I found a good deal of hits on google but they all just suggest defining BIND_8_COMPAT which doesn't help us. How can I realiably figure out what bind version a given resolver is using? Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From rmkml at wanadoo.fr Sat Jul 10 16:33:22 2004 From: rmkml at wanadoo.fr (rmkml) Date: Sun, 11 Jul 2004 01:33:22 +0200 (CEST) Subject: [Bro] Add timestamp micro in Logger.cc ? Message-ID: Hi, I use bro with syslog event, I would like add timestamp micro in Logger.cc, but I don't say, possible help me ? in hack this file / function in 09a2 please. Regards Rmkml at Wanadoo.fr if ( enabled ) { const char* sub_msg = msg; if ( has_timestamp ) { // Don't include the timestamp in the logging, // as it gets tacked on by syslog anyway. sub_msg = strchr(sub_msg, ' '); if ( sub_msg ) ++sub_msg; // skip over ' ' else sub_msg = msg; } syslog(LOG_NOTICE, "%s", sub_msg); } From vern at icir.org Sun Jul 11 10:34:17 2004 From: vern at icir.org (Vern Paxson) Date: Sun, 11 Jul 2004 10:34:17 -0700 Subject: new Bro releases Message-ID: <200407111734.i6BHYHDe088192@jaguar.icir.org> New CURRENT (0.9a3) and STABLE (0.8a87) releases are now available from: ftp://bro-ids.org/bro-pub-0.9-current.tar.gz ftp://bro-ids.org/bro-pub-0.8-stable.tar.gz The most significant changes are to ICMP procssing, including ICMP scan detection. The STABLE release fixes a bug: > - Fixed broken VLAN support (integration of original patch was incomplete). per the appended patch. Vern -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0.9a3 Wed Jul 7 22:06:26 PDT 2004 - Improved ICMP processing, including scan detection (Scott Campbell). - ICMP "connections" are now considered unidirectional. - Fixed broken VLAN support (integration of original patch was incomplete). - Fixed a bug in erroneously generating additional "ContentGap" alerts after an initial one. - Connection durations are now always reported as floating-point decimal, never in exponential notation. - Removed unused time parameter from a bunch of internal calls. - Fixed some compilation warnings. - "make clean" now removes generated policy/*.bif.bro files (Christian Kreibich). -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ diff -ru bro-pub-0.8a86/CHANGES bro-pub-0.8a87/CHANGES --- bro-pub-0.8a86/CHANGES Fri Jun 11 01:01:53 2004 +++ bro-pub-0.8a87/CHANGES Sun Jul 11 10:26:36 2004 @@ -1,6 +1,11 @@ -@(#) $Id: CHANGES,v 1.2 2004/06/06 17:42:53 vern Exp $ (LBL) +@(#) $Id: CHANGES,v 1.1 2004/07/11 17:25:57 vern Exp vern $ (LBL) -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +0.8a87 Sun Jul 11 10:26:35 PDT 2004 + +- Fixed broken VLAN support (integration of original patch was incomplete). 0.8a86 Fri Jun 11 01:01:49 PDT 2004 diff -ru bro-pub-0.8a86/Net.cc bro-pub-0.8a87/Net.cc --- bro-pub-0.8a86/Net.cc Sun Mar 21 09:23:38 2004 +++ bro-pub-0.8a87/Net.cc Sun Jul 11 10:24:48 2004 @@ -1,4 +1,4 @@ -// $Id: Net.cc,v 1.52 2004/03/21 17:23:25 vern Exp $ +// $Id: Net.cc,v 1.1 2004/07/11 17:24:11 vern Exp vern $ // // Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002 // The Regents of the University of California. All rights reserved. @@ -271,6 +271,30 @@ current_pktsrc = soonest_ps; pkt = soonest_ps->NextPacket(hdr); hdr_size = soonest_ps->HdrSize(); + + if ( encap_hdr_size > 0 ) + { + // We're doing tunnel encapsulation. Check whether there's + // a particular associated port. + if ( tunnel_port > 0 ) + { + struct ip* ip_hdr = (struct ip*) (pkt + hdr_size); + if ( ip_hdr->ip_p == IPPROTO_UDP ) + { + struct udphdr* udp_hdr = (struct udphdr*) + (pkt + hdr_size + ip_hdr->ip_hl * 4); + + if ( ntohs(udp_hdr->uh_dport) == tunnel_port ) + // A match. + hdr_size += encap_hdr_size; + } + } + + else + // Blanket encapsulation. + hdr_size += encap_hdr_size; + } + ts = soonest; if ( ! pkt ) diff -ru bro-pub-0.8a86/VERSION bro-pub-0.8a87/VERSION --- bro-pub-0.8a86/VERSION Fri Jun 11 00:58:49 2004 +++ bro-pub-0.8a87/VERSION Sun Jul 11 10:23:57 2004 @@ -1 +1 @@ -0.8a86 +0.8a87 From Terry.Barker at sas.com Mon Jul 12 10:18:01 2004 From: Terry.Barker at sas.com (Terry Barker) Date: Mon, 12 Jul 2004 13:18:01 -0400 Subject: simple pattern question Message-ID: <0C983BCA36926F4FA7C39A07A7525E560BC786@MERC22.na.sas.com> I'm a Bro newbie, so please forgive me if this is a trivial question. I'm experimenting with the signature module and did the following simple test: Using the file "ntp-attack.trace" in the example-attacks directory in the bro-pub-0.8a86 release. I used this signature file _________________________ signature testsig { payload /version/ event "signature_match" } _________________________ The word "version" occurs several times in the payloads in this file, as can be seen using tcpdump -X. This is the policy file I used (simplified from signatures.bro in the policy directory). _________________________ global sig_file = open_log_file("signatures"); event signature_match(state: signature_state, msg: string, data: string) { local id = state$id; local esc = escape_string(data); if ( byte_len(esc) > 20 ) esc = fmt( "%s...", sub_bytes(esc, 0, 20) ); print sig_file, fmt("SIGFILE %f %s/%d %s %s/%d %s %s [%s] %s", network_time(), state$conn$id$orig_h, state$conn$id$orig_p, state$is_orig ? ">" : "<", state$conn$id$resp_h, state$conn$id$resp_p, state$id, msg, esc, data ); print fmt("SIGH %f %s [%s] %s", network_time(), msg, esc, data ); } _________________________ When I run Bro with these files (and with no other policy files), there appear to be no matches. If instead, I match on the dst-ip, , i.e. using this signature file _________________________ signature testsig { dst-ip == 128.3.9.239 event "signature_match" } _________________________ I get the desired result (the correct connections are caught). Is something else required for the pattern feature? Thanks, Terry Barker From sommer at in.tum.de Tue Jul 13 02:44:53 2004 From: sommer at in.tum.de (Robin Sommer) Date: Tue, 13 Jul 2004 11:44:53 +0200 Subject: Question about Val serialization In-Reply-To: <1089398045.10880.39.camel@localhost.localdomain> References: <1089398045.10880.39.camel@localhost.localdomain> Message-ID: <20040713094453.GC12371@net.informatik.tu-muenchen.de> On Fri, Jul 09, 2004 at 11:34 -0700, you wrote: > My question is, why is it necessary to send the full type details along > with the val, and not just an identifier of the type? It seems to me There are two main reasons: - there isn't any direct assocation between types and identifiers; while for a given id you can see whether it's a type, it doesn't work the other way round: a type does not need to have a name (and even if it has, it may be hard to get access to it). - the value serialization is part of the larger picture which is serializing a full Bro configuration. In this context a certain type does not need to be known on the receiving side. > So, is there any chance that sending the type along will be optional in > the new serialization protocol? Actually, I've now completely removed the possibility to send a value w/o a type (as you have seen in the old code it was possible given that the receiving side could deduce the type somehow). Given the caching this works pretty good and makes things considerably cleaner. On the other hand, I can very well imagine a format in which, alternatively, a type can be specified by a string (e.g. which would then be looked up in the global ID space. Bro would probably not sent something like this itself but receiving it from Broccolli should be easy. So, the answer is yes. I'll add it. Robin -- Robin Sommer * Room 01.08.055 * www.net.in.tum.de TU Muenchen * Phone (089) 289-18006 * sommer at in.tum.de From christian at whoop.org Tue Jul 13 10:38:16 2004 From: christian at whoop.org (Christian Kreibich) Date: Tue, 13 Jul 2004 10:38:16 -0700 Subject: Question about Val serialization In-Reply-To: <20040713094453.GC12371@net.informatik.tu-muenchen.de> References: <1089398045.10880.39.camel@localhost.localdomain> <20040713094453.GC12371@net.informatik.tu-muenchen.de> Message-ID: <1089740295.901.679.camel@localhost.localdomain> On Tue, 2004-07-13 at 02:44, Robin Sommer wrote: [snipp!] > On the other hand, I can very well imagine a format in which, > alternatively, a type can be specified by a string (e.g. which would > then be looked up in the global ID space. Bro would probably not > sent something like this itself but receiving it from Broccolli > should be easy. So, the answer is yes. I'll add it. Okay great but don't add it as special treatment just for Broccoli! That'd make me feel bad :) Thanks for the details, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From sommer at in.tum.de Tue Jul 13 02:42:51 2004 From: sommer at in.tum.de (Robin Sommer) Date: Tue, 13 Jul 2004 11:42:51 +0200 Subject: simple pattern question In-Reply-To: <0C983BCA36926F4FA7C39A07A7525E560BC786@MERC22.na.sas.com> References: <0C983BCA36926F4FA7C39A07A7525E560BC786@MERC22.na.sas.com> Message-ID: <20040713094251.GB12371@net.informatik.tu-muenchen.de> On Mon, Jul 12, 2004 at 13:18 -0400, you wrote: > payload /version/ Try using /.*version/. The regexp is matched starting with the first byte of the payload. Robin -- Robin Sommer * Room 01.08.055 * www.net.in.tum.de TU Muenchen * Phone (089) 289-18006 * sommer at in.tum.de From Terry.Barker at sas.com Wed Jul 14 09:46:15 2004 From: Terry.Barker at sas.com (Terry Barker) Date: Wed, 14 Jul 2004 12:46:15 -0400 Subject: simple pattern question Message-ID: <0C983BCA36926F4FA7C39A07A7525E560BC797@MERC22.na.sas.com> Robin, Thanks for the reply. I had tried that. Still no luck. By the way, I didn't mention that I included the policy script ntp.bro on the command line when invoking bro. Terry > -----Original Message----- > From: Robin Sommer [mailto:sommer at in.tum.de] > Sent: Tuesday, July 13, 2004 2:43 AM > To: Terry Barker > Cc: bro at listserv.lbl.gov > Subject: Re: simple pattern question > > > On Mon, Jul 12, 2004 at 13:18 -0400, you wrote: > > > payload /version/ > > Try using /.*version/. The regexp is matched starting with the first > byte of the payload. > > Robin > > -- > Robin Sommer * Room 01.08.055 * www.net.in.tum.de > TU Muenchen * Phone (089) 289-18006 * sommer at in.tum.de From vern at icir.org Wed Jul 14 10:20:36 2004 From: vern at icir.org (Vern Paxson) Date: Wed, 14 Jul 2004 10:20:36 -0700 Subject: problems with Bro mailing list Message-ID: <200407141720.i6EHKaDe052602@jaguar.icir.org> The Bro mailing list is experiencing some significant problems at the moment (Hopefully you folks will receive this note!): (1) the archive is unretrievable, and (2) some posters who are indeed on the mailing list are having their posts denied as coming from a non-member. I am aiming to fix both these problems by moving the mailing list to a new home, hopefully by the end of the week. Sorry about the hassle .... Vern From vern at icir.org Wed Jul 14 12:58:03 2004 From: vern at icir.org (Vern Paxson) Date: Wed, 14 Jul 2004 12:58:03 -0700 Subject: simple pattern question In-Reply-To: Your message of Wed, 14 Jul 2004 12:46:15 EDT. Message-ID: <200407141958.i6EJw3De066750@jaguar.icir.org> > I had tried that. Still no luck. Be sure to double-check your setup. I ran your original signature and indeed there was no match, and then made the change to /.*version/ that Robin indicated and it now does indeed match. (no need to include ntp.bro, but it doesn't hurt either) Vern From Terry.Barker at sas.com Wed Jul 14 13:22:08 2004 From: Terry.Barker at sas.com (Terry Barker) Date: Wed, 14 Jul 2004 16:22:08 -0400 Subject: simple pattern question Message-ID: <0C983BCA36926F4FA7C39A07A7525E560BC799@MERC22.na.sas.com> OK, yeah that DOES do it. Thanks for your help. > -----Original Message----- > From: Vern Paxson [mailto:vern at icir.org] > Sent: Wednesday, July 14, 2004 12:58 PM > To: Terry Barker > Cc: Robin Sommer; bro at listserv.lbl.gov > Subject: Re: simple pattern question > > > I had tried that. Still no luck. > > Be sure to double-check your setup. I ran your original signature > and indeed there was no match, and then made the change to /.*version/ > that Robin indicated and it now does indeed match. (no need to include > ntp.bro, but it doesn't hurt either) > > Vern From vern at icir.org Wed Jul 21 10:30:34 2004 From: vern at icir.org (Vern Paxson) Date: Wed, 21 Jul 2004 10:30:34 -0700 Subject: [Bro] test #3 Message-ID: <200407211730.i6LHUYDe043238@jaguar.icir.org> From vern at icir.org Wed Jul 21 18:44:44 2004 From: vern at icir.org (Vern Paxson) Date: Wed, 21 Jul 2004 18:44:44 -0700 Subject: [Bro] mailing list migration complete Message-ID: <200407220144.i6M1iiDe071854@jaguar.icir.org> bro at bro-ids.org has now been moved over to its new home. I hope to have the recent postings in the archives by tomorrow. Vern From christian at whoop.org Thu Jul 22 10:14:05 2004 From: christian at whoop.org (Christian Kreibich) Date: Thu, 22 Jul 2004 10:14:05 -0700 Subject: [Bro] Re: No Subject In-Reply-To: References: Message-ID: <1090516445.30499.198.camel@localhost.localdomain> Hi, On Thu, 2004-07-22 at 07:55, Debra Dvorak wrote: > Hello, > > Thank you so much for your reply. You were correct. I did not need the > --with-package= part (I had thought maybe it was required for the it to > complile with the linux include directory...that is not true). I do > still have some questions and some clarifications to my earlier post: > when installing I've typed the following: > ./configure > make > make install > > the response I get from make install is as follows: > >bro /usr/local/sbin > > make: bro : Command not found > > make: *** [install] Error 127 oops you're right, sorry. It appears make install is broken at this point. We're not typically running make install here because Bro can run just fine from its build tree, but this will certainly need to be fixed. > Also another question. In the logs I am seeing "dropped 500 packets out > of 504" or similar...my guess is that my machine is not fast enough for > the event engine to process everything as it is being seen on the wire > so some packets are being dropped without analysis? I am using a nessus > scanning script against the network to see the response from bro....and > it tends to send out the packets very fast...this may be an unrealistic > attack since most attacks would not be as "noisy"...but it is a good way > of testing the system to see if it is "reading" packets and alerting. I > also have the capacity to upgrade double the system memory and will be > doing that soon. Well even if Nessus sends quickly, Bro shouldn't miss 99% of the packets :) If the counters you're referring to are the ones pcap reports, then the reason may be that packet counters are handled differently on Linux and BSD. Do not trust these counters on Linux. Good luck, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From alrenaud at swissinfo.org Thu Jul 15 19:32:05 2004 From: alrenaud at swissinfo.org (alrenaud at swissinfo.org) Date: Fri, 16 Jul 2004 02:32:05 +0000 Subject: GnuPG signing Message-ID: <3F585D6600087FF5@mail.swissinfo.org> Are there any plans for (GnuPG) signing bro?s distribution files? _______________________________________________________________________ Dreaming of a Swiss Account? Get it here: http://freemail.swissinfo.org From zangds at netpower.com.cn Sun Jul 18 20:00:15 2004 From: zangds at netpower.com.cn (=?utf-8?B?6Ien5Yas5p2+?=) Date: Mon, 19 Jul 2004 11:00:15 +0800 Subject: About MAC address References: <1089398045.10880.39.camel@localhost.localdomain> <20040713094453.GC12371@net.informatik.tu-muenchen.de> Message-ID: <001801c46d3c$84507ff0$7400a8c0@netpowerdonal> Hi,Robin For some reason,I want to get the MAC address info in the policy file,can U tell me how? Regards! From vern at icir.org Sun Jul 18 20:20:05 2004 From: vern at icir.org (Vern Paxson) Date: Sun, 18 Jul 2004 20:20:05 -0700 Subject: About MAC address In-Reply-To: Your message of Mon, 19 Jul 2004 11:00:15 +0800. Message-ID: <200407190320.i6J3K5De097396@jaguar.icir.org> > For some reason,I want to get the MAC address info in the policy file,can > U tell me how? Bro does not currently make any MAC address information available to policy scripts. This likely won't change unless there's a fairly compelling motivation for it. Vern From vern at icir.org Mon Jul 19 13:24:36 2004 From: vern at icir.org (Vern Paxson) Date: Mon, 19 Jul 2004 13:24:36 -0700 Subject: GnuPG signing In-Reply-To: Your message of Fri, 16 Jul 2004 02:32:05 -0000. Message-ID: <200407192024.i6JKOaDe097659@jaguar.icir.org> > Are there any plans for (GnuPG) signing > bro?s distribution files? I hadn't been planning to do so, but we could if folks would prefer so and would actually validate the signatures. Could those who have an opinion send me private email so I can get a sense of whether this is worth the effort? Vern From vern at icir.org Tue Jul 20 00:39:19 2004 From: vern at icir.org (Vern Paxson) Date: Tue, 20 Jul 2004 00:39:19 -0700 Subject: compile problems on Mac OS X (with XCode 1.2 and BIND9) In-Reply-To: Your message of Fri, 09 Jul 2004 18:31:46 PDT. Message-ID: <200407200739.i6K7dJDe016297@jaguar.icir.org> > What I'm doing in the attached patch is > > 1. check whether you're running Darwin > 2. if so, test whether just including arpa/nameser.h gives you HEADER > 3. if 2 fails, include arpa/nameser_compat.h and use -lresolv instead of > /usr/lib/libresolv.a Thanks, I've integrated this and it'll be included in the next release. My Darwin setup is evidently a bit unusual (since I didn't encounter the problems that Ruoming & Brian did), so if others can please test this when it goes out, I'd appreciate it. Vern From Thomas.Scheffler at t-systems.com Tue Jul 20 02:01:49 2004 From: Thomas.Scheffler at t-systems.com (Scheffler, Thomas) Date: Tue, 20 Jul 2004 11:01:49 +0200 Subject: AW: Bro IPv6 Message-ID: Hi Vern, I am currently looking for an IDS which has 'full' IPv6 support. IPv6 is growing (althrough sometimes silently) and the worst scenario would be that it gets the stigma that its the protocol of choice for malicious wrongdoing since it has become the backdoor into your network. If we are going to offer customers dual stack IPv4/IPv6 access and there is no adequate support from the security tools that he/she normally uses this can easily happen without even noticing, since we lack the tools to look for this sort of activity. I have compiled it with the IPv6 option. How do I tell that IPv6 is working in Bro at all? I don't see any events for IPv6 generated. Regards, Thomas > -----Ursprungliche Nachricht----- > Von: Vern Paxson [mailto:vern at icir.org] > Gesendet: Samstag, 17. Juli 2004 01:25 > An: Scheffler, Thomas > Betreff: Re: Bro IPv6 > > > > What is the status of IPv6 support in Bro? > > Bro supports IPv6 headers/addresses if configured using > --enable-brov6. > (It doesn't have any support for IPv6 options or ICMPs.) There's some > bitrot in the code, though (it was developed quite a while ago, and we > don't yet use it operationally), so it needs updating. This probably > won't happen for a while, as it's not currently a priority for us. > > Vern > From ddvorak at cccc.edu Tue Jul 20 10:10:55 2004 From: ddvorak at cccc.edu (Debra Dvorak) Date: Tue, 20 Jul 2004 13:10:55 -0400 Subject: No subject Message-ID: Hello, I am attempting to install and study bro as a grad project. I have RH 9 installed and all updates done. I have not hardened the system yet because I don't want to disable something that will interfere with the IDS. I have the following installed (in installation order): perl-Tk-804.027-8.rh9, zlib-1.2.1, libpcap-0.8.3, tcpdump-3.8.3, mysql-4.0.15a, httpd-2.0.50, php-4.3.3. I downloaded bro (bro-pub-0.8a87) to /root/bro directory and untarred. I've tried installation with: ./configure --with-PACKAGE=linux-include, make, make install. I am getting an error at the make install as follows: bro /usr/local/sbin make: bro : Command not found make: *** [install] Error 127 I've tried a couple of things: ./bro -r example-attacks/ntp-attack.trace mt this command gives some expected errors about scan.bro variables, etc...but also gives the log of the session. Using cat weird.log gives the following: 986505326.451411 128.3.9.239 > 128.3.9.62/ntp: truncated ntp. using ./bro -i eth0 -w testinglog.trace mt yields the same expected errors and then "listening on eth0" but when I end (ctl C). I get "0 packets recieved on interface eth0, 0 dropped" with the nic operating both with an ip address and in "stealth mode". I am running nessus against the network and ethereal on the network to detect the traffic so there should be some traffic picked up on the interface (or I would expect it to be). cat testlog.trace gives either nothing or the following error: ./bro: problem with trace file testlog.trace -fread; inappropriate ioctl for device. Can someone please help me determine what is going wrong with the installation and how to get bro to "see" the traffic? Thank you in advance. Best Regards, Deb From christian at whoop.org Tue Jul 20 12:02:31 2004 From: christian at whoop.org (Christian Kreibich) Date: Tue, 20 Jul 2004 12:02:31 -0700 Subject: No Subject In-Reply-To: References: Message-ID: <1090350151.30497.65.camel@localhost.localdomain> Hi Deb, I'm not quite sure I understand some of the details below so I'll just point things out that sound odd ... On Tue, 2004-07-20 at 10:10, Debra Dvorak wrote: > Hello, > > I am attempting to install and study bro as a grad project. I have RH 9 > installed and all updates done. I have not hardened the system yet > because I don't want to disable something that will interfere with the > IDS. > > I have the following installed (in installation order): > perl-Tk-804.027-8.rh9, zlib-1.2.1, libpcap-0.8.3, tcpdump-3.8.3, > mysql-4.0.15a, httpd-2.0.50, php-4.3.3. > > I downloaded bro (bro-pub-0.8a87) to /root/bro directory and untarred. > I've tried installation with: ./configure --with-PACKAGE=linux-include, I think you can leave out the --with-PACKAGE stuff? "PACKAGE" is meant to be replaced with the name of an optional package, like openssl or mpatrol. I think the statement has no effect though. > make, make install. I am getting an error at the make install as > follows: > bro /usr/local/sbin > make: bro : Command not found > make: *** [install] Error 127 Just run "make install", not "make install bro" :) > I've tried a couple of things: > > ./bro -r example-attacks/ntp-attack.trace mt this command gives some > expected errors about scan.bro variables, etc...but also gives the log > of the session. Using cat weird.log gives the following: > 986505326.451411 128.3.9.239 > 128.3.9.62/ntp: truncated ntp. So that means you can basically run Bro reading trace files. Cool. > using ./bro -i eth0 -w testinglog.trace mt yields the same expected > errors and then "listening on eth0" but when I end (ctl C). I get "0 > packets recieved on interface eth0, 0 dropped" with the nic operating > both with an ip address and in "stealth mode". I am running nessus > against the network and ethereal on the network to detect the traffic so > there should be some traffic picked up on the interface (or I would > expect it to be). There are two points to consider here: 1) does ethereal show you any traffic, and 2) do the analyzers you load into Bro care about this traffic. Loading the mt policy script would suggest so ... > cat testlog.trace gives either nothing or the > following error: > ./bro: problem with trace file testlog.trace -fread; inappropriate ioctl > for device. This again is about running Bro reading a trace file, right? It seems you currently get this message when you try to read from an empty trace file (a zero length file, not an empty tcpdump trace file, which still contains some data). We'll look into it -- in the meantime try to read from a trace file that contains a few packets :) Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From vern at icir.org Tue Jul 20 14:39:50 2004 From: vern at icir.org (Vern Paxson) Date: Tue, 20 Jul 2004 14:39:50 -0700 Subject: AW: Bro IPv6 In-Reply-To: Your message of Tue, 20 Jul 2004 11:01:49 +0200. Message-ID: <200407202139.i6KLdoDe036872@jaguar.icir.org> > I have compiled it with the IPv6 option. I don't think you could have (you do so by configuring using "./configure --enable-brov6"), because currently the sources don't compile due to the introduction of uses of addresses (for example, in bro.bif) which need additional code to build when addresses occupy > 1 word. As I mentioned, this will eventually be fixed, but it's not a priority for us at the moment due to more pressing needs. If you want to contribute patches, that would certainly be welcome. Vern From vern at icir.org Wed Jul 21 11:08:51 2004 From: vern at icir.org (Vern Paxson) Date: Wed, 21 Jul 2004 11:08:51 -0700 Subject: moving the Bro mailing list Message-ID: <200407211808.i6LI8pDe052629@jaguar.icir.org> The Bro mailing list bro at bro-ids.org, which is currently hosted at bro at lbl.gov, is being moved to bro at icsi.berkeley.edu. I've copied over the subscriber list and you should have already (or soon) received an email message from mailman-owner with your subscriber information. The list is "live" but I haven't yet switched bro at bro-ids.org over to it yet. I'll send a note when that happens. In the interim, you can use bro at icsi.berkeley.edu directly (though in general, bro at bro-ids.org is preferred). A significant benefit of the new setup is Web-accessible archives. These are in place except for the past few days of traffic, which I'm looking into getting copied over, too. If you encounter any initial problems, let me know. Vern From christian at whoop.org Mon Jul 26 22:48:10 2004 From: christian at whoop.org (Christian Kreibich) Date: Mon, 26 Jul 2004 22:48:10 -0700 Subject: [Bro] Broccoli 0.5 Message-ID: <1090907288.9697.193.camel@localhost.localdomain> Hi, I've managed to create a native win32 DLL build of Broccoli, using the MinGW environment (http://www.mingw.org) and the OpenSSL libraries listed on http://www.openssl.org/related/binaries.html . Evidence: http://www.cl.cam.ac.uk/~cpk25/broping.gif This is broping running inside vmware on my laptop and pinging out to Bro running on the Linux host system. (Apologies for the German window title -- this is an installation of a Windows 98 CD that has a long tradition in my family :) MinGW rocks. I was able to use the entire gnuish build environment including libtool, and moving to OpenSSL eliminated almost all platform-dependent stuff. I can't seem to figure out nonblocking I/O on Windows right now so it's blocking for the moment, but it's in the works. The new 0.5 release + the windows binaries are here in case you want to give it a try: http://www.cl.cam.ac.uk/~cpk25/downloads/broccoli/ Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From chema at cs.berkeley.edu Thu Jul 29 12:18:34 2004 From: chema at cs.berkeley.edu (=?iso-8859-1?q?Jos=E9_Mar=EDa_Gonz=E1lez?=) Date: Thu, 29 Jul 2004 12:18:34 -0700 Subject: [Bro] On Modifying Bro tables in C++ Message-ID: <200407291218.34822.chema@cs.berkeley.edu> Hi, The following problem is probably easy, but my knowledge of C++ is pretty limited. I have a table defined in Bro, and I want to modify it (add/delete terms) in C++. Actually, I want to modify the table *only* in C++, but this is another subject. I use internal_val() to get a Val* from the table's Bro name. When I want to read the table, I access to the table underneath using my_table->AsTable() or, if I want to do further casting, using my_table->AsTable()->AsTableVal(). Everything works fine. Problem is when I want to write. AsTable() is defined in Val.h as a const accessor, but not as a non-const one. This means that my_table->AsTable() returns actually a "const TableEntryValPDict" object. Therefore, any access to Insert() or Remove() causes a "discards qualifiers" compiler error. While I can do brute-force cast and turn my "const TableEntryValPDict" into a simple TableEntryValPDict, I've read in Val.h that "Accessors for mutable values are called AsNonConst* and are protected to avoid external state changes." This seems to state that there is a valid reason to avoid doing what I'm doing. "Avoid external state changes" is not descriptive enough for me. Can somebody provide advice on this? TIA. -Chema From rpang at CS.Princeton.EDU Thu Jul 29 13:53:28 2004 From: rpang at CS.Princeton.EDU (Ruoming Pang) Date: Thu, 29 Jul 2004 16:53:28 -0400 Subject: [Bro] On Modifying Bro tables in C++ In-Reply-To: <200407291218.34822.chema@cs.berkeley.edu> References: <200407291218.34822.chema@cs.berkeley.edu> Message-ID: <57E0C58E-E1A1-11D8-B0F9-000D9335A7D8@cs.princeton.edu> > Problem is when I want to write. AsTable() is defined in > Val.h as a const accessor, but not as a non-const one. Hi, Chema, How about using TableVal::Assign()? Ruoming From sommer at in.tum.de Fri Jul 30 00:56:23 2004 From: sommer at in.tum.de (Robin Sommer) Date: Fri, 30 Jul 2004 09:56:23 +0200 Subject: [Bro] On Modifying Bro tables in C++ In-Reply-To: <200407291218.34822.chema@cs.berkeley.edu> References: <200407291218.34822.chema@cs.berkeley.edu> Message-ID: <20040730075623.GE12807@net.informatik.tu-muenchen.de> On Thu, Jul 29, 2004 at 12:18 -0700, Jos? Mar?a Gonz?lez wrote: > read in Val.h that "Accessors for mutable values are called > AsNonConst* and are protected to avoid external state > changes." The reason for the accessors being protected is the new &synchronized keyword (and other related issues). For synchronizing values between remote instances of Bro, we need to track all accesses to the table which change its state in some way. The code of TableVal (and derived classes) takes care of this. If you modify the values content from the outside you have to do it yourself (grep for LogAccess to see how that works). So, I'd also suggest to use TableVal::Assign(). Robin -- Robin Sommer * Room 01.08.055 * www.net.in.tum.de TU Muenchen * Phone (089) 289-18006 * sommer at in.tum.de From chema at cs.berkeley.edu Fri Jul 30 17:29:20 2004 From: chema at cs.berkeley.edu (=?iso-8859-1?q?Jos=E9_Mar=EDa_Gonz=E1lez?=) Date: Fri, 30 Jul 2004 17:29:20 -0700 Subject: [Bro] On Modifying Bro tables in C++ In-Reply-To: <20040730075623.GE12807@net.informatik.tu-muenchen.de> References: <200407291218.34822.chema@cs.berkeley.edu> <20040730075623.GE12807@net.informatik.tu-muenchen.de> Message-ID: <200407301729.20253.chema@cs.berkeley.edu> Robin, Thanks for the answer. Ruoming convinced me first (it's easier), but you answer my real doubt (why such a centralization of access). Regards. -Chema On Friday 30 July 2004 00:56, Robin Sommer wrote: > > On Thu, Jul 29, 2004 at 12:18 -0700, Jos? Mar?a Gonz?lez wrote: > > > read in Val.h that "Accessors for mutable values are called > > AsNonConst* and are protected to avoid external state > > changes." > > The reason for the accessors being protected is the new > &synchronized keyword (and other related issues). For synchronizing > values between remote instances of Bro, we need to track all > accesses to the table which change its state in some way. The code > of TableVal (and derived classes) takes care of this. If you modify > the values content from the outside you have to do it yourself (grep > for LogAccess to see how that works). > > So, I'd also suggest to use TableVal::Assign(). > > Robin >