From mikeh at ncsa.uiuc.edu Mon Feb 3 17:12:31 2003 From: mikeh at ncsa.uiuc.edu (Mike Haberman) Date: Mon, 3 Feb 2003 19:12:31 -0600 Subject: Bro 0.8 and vlans Message-ID: <20030203191231.D28246@ncsa.uiuc.edu> Hi, I'm a recent subscriber, so if this has been covered, please point me. I am working on getting bro bro-pub-0.8a20 up and running on freebsd box. We have bro-pub-0.7a90 running using an old hacked version of libpcap to handle vlans. Anyway, I've updated to 0.7 of libpcap and compiled bro 0.8. in my policy file: redef restrict_filter = "vlan"; so my resulting filter is (((((((((((ip[6:2] & 0x3fff != 0) and tcp) or (tcp[13] & 7 != 0)) or (port finger)) or (tcp port 113)) or (port ftp)) or (port telnet or tcp port 513)) or (port 111)) or (udp port 123)) or (udp port 69)) and vlan) libpcap promptly complains: expression rejects all packets however if I rephrase it to be: (vlan and ((((((((((ip[6:2] & 0x3fff != 0) and tcp) or (tcp[13] & 7 != 0)) or (port finger)) or (tcp port 113)) or (port ftp)) or (port telnet or tcp port 513)) or (port 111)) or (udp port 123)) or (udp port 69))) no problem. tcpdump works fine with the above expression.. seems to work :) so now, in bro, I use the redef capture_filter = bro runs, but no packets are being captured. (i.e bro -w tcp policyFile; the tcp file is empty) I also updated the PktSrc::SetHdrSize() to be DLT_EN10MB: hdr_size = 18; /* it was 14 */ but still no luck.. can anyone help me out?? thanks a ton, mike haberman NCSA From anton at netForensics.com Tue Feb 4 09:11:07 2003 From: anton at netForensics.com (Anton Chuvakin, Ph.D.) Date: Tue, 4 Feb 2003 12:11:07 -0500 (EST) Subject: compile on RedHat Linux? Message-ID: All, Anybody knows why is that? g++ -o bro main.o net_util.o util.o parse.o scan.o re-parse.o re-scan.o rule-parse.o rule-scan.o Active.o Anon.o Attr.o BackDoor.o BroString.o CCL.o CompHash.o Conn.o DFA.o Debug.o DebugCmds.o DbgBreakpoint.o DbgWatch.o DbgHelp.o Desc.o Dict.o Discard.o DNS.o DNS_Mgr.o EquivClass.o Event.o Expr.o File.o Finger.o Frag.o Frame.o FTP.o Func.o Hash.o HTTP.o ICMP.o ID.o Ident.o InterConn.o IntSet.o List.o Logger.o Login.o MIME.o NFA.o NTP.o NVT.o Net.o NetbiosSSN.o NetVar.o Obj.o PktSrc.o PolicyFile.o Portmap.o PriorityQueue.o Queue.o Reassem.o Rlogin.o RE.o RPC.o Rule.o RuleMatcher.o RuleAction.o RuleCondition.o Scope.o Sessions.o SMTP.o SSH.o SteppingStone.o Stmt.o TCP.o TCP_Rewriter.o Telnet.o Timer.o Type.o UDP.o Val.o Var.o XDR.o cq.o md5.o setsignal.o version.o nb_dns.o -Llibedit -ltermcap -ledit -lresolv -lpcap -lm nb_dns.o: In function `nb_dns_activity': nb_dns.o(.text+0x678): undefined reference to `__ns_initparse' nb_dns.o(.text+0x742): undefined reference to `_ns_flagdata' nb_dns.o(.text+0x748): undefined reference to `_ns_flagdata' nb_dns.o(.text+0x9bc): undefined reference to `__ns_parserr' collect2: ld returned 1 exit status make: *** [bro] Error 1 System: # Linux bastion 2.4.18-3 #1 Thu Apr 18 07:37:53 EDT 2002 i686 unknown # Red Hat Linux release 7.3 (Valhalla) -- Anton Chuvakin, Ph.D., GCIA Senior Security Analyst netForensics - http://www.netForensics.com 732-393-6071 From vern at icir.org Thu Feb 6 22:02:19 2003 From: vern at icir.org (Vern Paxson) Date: Thu, 06 Feb 2003 22:02:19 -0800 Subject: Bro 0.8 and vlans In-Reply-To: Your message of Mon, 03 Feb 2003 19:12:31 CST. Message-ID: <200302070602.h1762J3I052422@jaguar.icir.org> > in my policy file: redef restrict_filter = "vlan"; Oops. Unfortunately, "vlan" is a hack bolted onto tcpdump/libpcap. I discussed bugs in it that Bro tickled with Bill Fenner a while ago. Here's the tail end of that thread, which included a patch that worked for one of your NCSA colleagues. > no problem. tcpdump works fine with the above expression.. seems to work :) > > so now, in bro, I use the redef capture_filter = There were also some related problems with Bro reading from multiple interfaces, because the vlan keyword diddles the hdr_size in a non-reentrant way (or at least it used to), but I don't know if that's what's tripping you up or not. Does Bro work okay for you w/o the "vlan"? Vern Date: Mon, 5 Nov 2001 00:02:49 -0600 From: Jon Dugan Subject: Re: expression rejects all packets To: Bill Fenner Cc: vern at ee.lbl.gov, tony at ncsa.uiuc.edu X-Envelope-From: jdugan at ncsa.uiuc.edu Resent-To: fenner at research.att.com, vern at ee.lbl.gov Bill, Well, I finally got a chance to try this patch -- it does indeed fix the problem. Thanks! On Wed, Sep 12, 2001 at 08:47:34PM -0700, Bill Fenner wrote: > > Here's a not very elegant patch to try; it fixes the multiple compilation > problem in my test program (not bro, just a filter expression tester). > > Bill > > Index: gencode.c > =================================================================== > RCS file: /tcpdump/master/libpcap/gencode.c,v > retrieving revision 1.157 > diff -u -r1.157 gencode.c > --- gencode.c 2001/07/03 19:15:47 1.157 > +++ gencode.c 2001/09/13 03:36:41 > @@ -78,6 +78,9 @@ > static jmp_buf top_ctx; > static pcap_t *bpf_pcap; > > +/* Hack for updating VLAN offsets. */ > +static u_int orig_linktype = -1, orig_nl = -1; > + > /* XXX */ > #ifdef PCAP_FDDIPAD > int pcap_fddipad = PCAP_FDDIPAD; > @@ -551,6 +554,9 @@ > { > linktype = type; > > + orig_linktype = -1; > + orig_nl = -1; > + > switch (type) { > > case DLT_ARCNET: > @@ -3873,7 +3879,6 @@ > gen_vlan(vlan_num) > int vlan_num; > { > - static u_int orig_linktype = -1, orig_nl = -1; > struct block *b0; > > /* -- Jon Dugan | Senior Network Engineer, NCSA Network Development jdugan at ncsa.uiuc.edu | 269 CAB, 605 E Springfield, Champaign, IL 61820 217-244-7715 | http://www.ncsa.uiuc.edu/people/jdugan From rpang at icir.org Fri Feb 7 10:03:22 2003 From: rpang at icir.org (Ruoming Pang) Date: Fri, 7 Feb 2003 10:03:22 -0800 (PST) Subject: compile on RedHat Linux? In-Reply-To: Message-ID: Here is the answer I got when I posted the same question on the mailing list: (I do not have the answer for my last question about the internal_error -- anybody knows a solution?) Ruoming Date: Wed, 4 Dec 2002 17:18:17 -0800 (PST) From: Ruoming Pang To: grd-pub.56 at NOSPAMnetcourrier.com Subject: Re: building bro in linux Thanks! It does solve the link problem. But as I try to run bro, DNS_Mgr complained about an internal_error from nb_dns. I guess I need to get a newer version of libresolv? Ruoming On Wed, 4 Dec 2002 grd-pub.56 at NOSPAMnetcourrier.com wrote: > Hi, > > You should try linking with "/usr/lib/libresolv.a" instead of "-lresolv" -- > the latter uses the dynamic library, libresolv.so, unless you add the > "-static" option. Just edit the Makefile accordingly. > > Good luck, > > Olivier. > > > On Wednesday 04 December 2002 07:02 am, you wrote: > > Hi, > > > > I wonder anyone has experience in building Bro in linux and, especially, > > in resolving the following problem: > > > > nb_dns.o: In function `nb_dns_activity': > > nb_dns.o(.text+0x678): undefined reference to `__ns_initparse' > > nb_dns.o(.text+0x742): undefined reference to `_ns_flagdata' > > nb_dns.o(.text+0x748): undefined reference to `_ns_flagdata' > > nb_dns.o(.text+0x9bc): undefined reference to `__ns_parserr' > > collect2: ld returned 1 exit status > > make: *** [bro] Error 1 > > > > I am using linux 2.4.18-3 (Redhat 7.3). I nm'ed libresolv.a and did find > > __ns_initparse in it: > > > > /usr/lib/libresolv.a:ns_parse.o:00000000 T __ns_initparse > > > > Thanks a lot, > > Ruoming > On Tue, 4 Feb 2003, Anton Chuvakin, Ph.D. wrote: > All, > > Anybody knows why is that? > > g++ -o bro main.o net_util.o util.o parse.o scan.o re-parse.o re-scan.o > rule-parse.o rule-scan.o Active.o Anon.o Attr.o BackDoor.o BroString.o > CCL.o CompHash.o Conn.o DFA.o Debug.o DebugCmds.o DbgBreakpoint.o > DbgWatch.o DbgHelp.o Desc.o Dict.o Discard.o DNS.o DNS_Mgr.o EquivClass.o > Event.o Expr.o File.o Finger.o Frag.o Frame.o FTP.o Func.o Hash.o HTTP.o > ICMP.o ID.o Ident.o InterConn.o IntSet.o List.o Logger.o Login.o MIME.o > NFA.o NTP.o NVT.o Net.o NetbiosSSN.o NetVar.o Obj.o PktSrc.o PolicyFile.o > Portmap.o PriorityQueue.o Queue.o Reassem.o Rlogin.o RE.o RPC.o Rule.o > RuleMatcher.o RuleAction.o RuleCondition.o Scope.o Sessions.o SMTP.o SSH.o > SteppingStone.o Stmt.o TCP.o TCP_Rewriter.o Telnet.o Timer.o Type.o UDP.o > Val.o Var.o XDR.o cq.o md5.o setsignal.o version.o nb_dns.o -Llibedit > -ltermcap -ledit -lresolv -lpcap -lm > > nb_dns.o: In function `nb_dns_activity': > nb_dns.o(.text+0x678): undefined reference to `__ns_initparse' > nb_dns.o(.text+0x742): undefined reference to `_ns_flagdata' > nb_dns.o(.text+0x748): undefined reference to `_ns_flagdata' > nb_dns.o(.text+0x9bc): undefined reference to `__ns_parserr' > collect2: ld returned 1 exit status > > make: *** [bro] Error 1 > > System: > > # Linux bastion 2.4.18-3 #1 Thu Apr 18 07:37:53 EDT 2002 i686 unknown > # Red Hat Linux release 7.3 (Valhalla) > > -- > Anton Chuvakin, Ph.D., GCIA > Senior Security Analyst > netForensics - http://www.netForensics.com > 732-393-6071 > From grd-pub.56 at NOSPAMnetcourrier.com Fri Feb 7 10:45:55 2003 From: grd-pub.56 at NOSPAMnetcourrier.com (grd-pub.56 at NOSPAMnetcourrier.com) Date: Fri, 7 Feb 2003 19:45:55 +0100 Subject: compile on RedHat Linux? In-Reply-To: References: Message-ID: <20030207184115.7556515E33@postfix4-1.free.fr> Hi, This is probably a name service configuration/connectivity issue. You should check the "nameserver" declarations in your /etc/resolv.conf, and make sure that the DNS servers are reachable from your bro box. Olivier. On Friday 07 February 2003 07:03 pm, Ruoming Pang wrote: > Here is the answer I got when I posted the same question on the mailing > list: (I do not have the answer for my last question about the > internal_error -- anybody knows a solution?) > > Ruoming > > Date: Wed, 4 Dec 2002 17:18:17 -0800 (PST) > From: Ruoming Pang > To: grd-pub.56 at NOSPAMnetcourrier.com > Subject: Re: building bro in linux > > Thanks! It does solve the link problem. But as I try to run bro, DNS_Mgr > complained about an internal_error from nb_dns. I guess I need to get a > newer version of libresolv? > > Ruoming > > On Wed, 4 Dec 2002 grd-pub.56 at NOSPAMnetcourrier.com wrote: > > Hi, > > > > You should try linking with "/usr/lib/libresolv.a" instead of > > "-lresolv" -- > > > the latter uses the dynamic library, libresolv.so, unless you add the > > "-static" option. Just edit the Makefile accordingly. > > > > Good luck, > > > > Olivier. > > > > On Wednesday 04 December 2002 07:02 am, you wrote: > > > Hi, > > > > > > I wonder anyone has experience in building Bro in linux and, > > especially, > > > > in resolving the following problem: > > > > > > nb_dns.o: In function `nb_dns_activity': > > > nb_dns.o(.text+0x678): undefined reference to `__ns_initparse' > > > nb_dns.o(.text+0x742): undefined reference to `_ns_flagdata' > > > nb_dns.o(.text+0x748): undefined reference to `_ns_flagdata' > > > nb_dns.o(.text+0x9bc): undefined reference to `__ns_parserr' > > > collect2: ld returned 1 exit status > > > make: *** [bro] Error 1 > > > > > > I am using linux 2.4.18-3 (Redhat 7.3). I nm'ed libresolv.a and did > > find > > > > __ns_initparse in it: > > > > > > /usr/lib/libresolv.a:ns_parse.o:00000000 T __ns_initparse > > > > > > Thanks a lot, > > > Ruoming > > On Tue, 4 Feb 2003, Anton Chuvakin, Ph.D. wrote: > > All, > > > > Anybody knows why is that? > > > > g++ -o bro main.o net_util.o util.o parse.o scan.o re-parse.o re-scan.o > > rule-parse.o rule-scan.o Active.o Anon.o Attr.o BackDoor.o BroString.o > > CCL.o CompHash.o Conn.o DFA.o Debug.o DebugCmds.o DbgBreakpoint.o > > DbgWatch.o DbgHelp.o Desc.o Dict.o Discard.o DNS.o DNS_Mgr.o EquivClass.o > > Event.o Expr.o File.o Finger.o Frag.o Frame.o FTP.o Func.o Hash.o HTTP.o > > ICMP.o ID.o Ident.o InterConn.o IntSet.o List.o Logger.o Login.o MIME.o > > NFA.o NTP.o NVT.o Net.o NetbiosSSN.o NetVar.o Obj.o PktSrc.o PolicyFile.o > > Portmap.o PriorityQueue.o Queue.o Reassem.o Rlogin.o RE.o RPC.o Rule.o > > RuleMatcher.o RuleAction.o RuleCondition.o Scope.o Sessions.o SMTP.o > > SSH.o SteppingStone.o Stmt.o TCP.o TCP_Rewriter.o Telnet.o Timer.o Type.o > > UDP.o Val.o Var.o XDR.o cq.o md5.o setsignal.o version.o nb_dns.o > > -Llibedit -ltermcap -ledit -lresolv -lpcap -lm > > > > nb_dns.o: In function `nb_dns_activity': > > nb_dns.o(.text+0x678): undefined reference to `__ns_initparse' > > nb_dns.o(.text+0x742): undefined reference to `_ns_flagdata' > > nb_dns.o(.text+0x748): undefined reference to `_ns_flagdata' > > nb_dns.o(.text+0x9bc): undefined reference to `__ns_parserr' > > collect2: ld returned 1 exit status > > > > make: *** [bro] Error 1 > > > > System: > > > > # Linux bastion 2.4.18-3 #1 Thu Apr 18 07:37:53 EDT 2002 i686 unknown > > # Red Hat Linux release 7.3 (Valhalla) > > > > -- > > Anton Chuvakin, Ph.D., GCIA > > Senior Security Analyst > > netForensics - http://www.netForensics.com > > 732-393-6071 From anton at netForensics.com Fri Feb 7 11:36:10 2003 From: anton at netForensics.com (Anton Chuvakin, Ph.D.) Date: Fri, 7 Feb 2003 14:36:10 -0500 (EST) Subject: useful *.bro files repository? Message-ID: Vern and all, Bro is up and running on our site, thanks to this list for the help with the compilation! I was wondering if there is (or SHOULD BE) a repository of useful *.bro policies to use for different cases. Right now I am running with '@load mt' and some other @load's which I semi-intelligently selected from the policies dir, but I noticed there is a bunch of other fun bro files. Which of them are useful and when? Also, I understand that rules.bro is undocumented, but can I get ANY hints on its functionality beyond what I can figure from looking at the files itself...? BTW, I was also about to ask how to best collect and analyze alerts, but I my have an answer to this one. Our product might soon collect Bro alerts and report on them (in the context of other security event messages). Best, -- Anton Chuvakin, Ph.D., GCIA - http://www.info-secure.org Senior Security Analyst netForensics - http://www.netForensics.com 732-393-6071 From jdugan at ncsa.uiuc.edu Fri Feb 7 18:14:08 2003 From: jdugan at ncsa.uiuc.edu (Jon Dugan) Date: Fri, 7 Feb 2003 20:14:08 -0600 Subject: bro and FreeBSD 5.0 Message-ID: <20030208021407.GA2444@ncsa.uiuc.edu> I've been trying to get bro to compile properly under FreeBSD 5.0. It looks like the change to gcc3 broke some things. I've attached a patch that gets the compile further along than initially, but I got stuck. Of course this causes the compiler to kvetch about using depricated headers. Here's the error message that has me stumped: g++ -I. -Ilibedit -O -c DebugCmds.cc In file included from /usr/include/g++/backward/map.h:59, from Type.h:29, from ID.h:25, from Expr.h:28, from Debug.h:25, from DebugCmds.cc:11: /usr/include/g++/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the header for the header for C++ includes, or instead of the deprecated header . To disable this warning use -Wno-deprecated. DebugCmds.cc: In function `int find_all_matching_cmds(const std::string&, const char**)': DebugCmds.cc:164: invalid conversion from `const char*' to `unsigned int' DebugCmds.cc:164: initializing argument 1 of `int std::basic_string<_CharT, _Traits, _Alloc>::compare(_Alloc::size_type, _Alloc::size_type, const _CharT*) const [with _CharT = char, _Traits = std::char_traits, _Alloc = std::allocator]' DebugCmds.cc:164: invalid conversion from `unsigned int' to `const char*' DebugCmds.cc:164: initializing argument 3 of `int std::basic_string<_CharT, _Traits, _Alloc>::compare(_Alloc::size_type, _Alloc::size_type, const _CharT*) const [with _CharT = char, _Traits = std::char_traits, _Alloc = std::allocator]' *** Error code 1 I can't seem to get it to find the hash<> templates. I'm guessing that someone with more experience in C++ would be able to see what's going on. I have very little experience with templates, etc in C++. Also, the parse.y doesn't seem to be compatible with bison, I had to force the Makefile to use the system yacc (byacc). Jon -- Jon Dugan | Senior Network Engineer, NCSA Network Research jdugan at ncsa.uiuc.edu | 269 CAB, 605 E Springfield, Champaign, IL 61820 217-244-7715 | http://www.ncsa.uiuc.edu/~jdugan/ -------------- next part -------------- diff -rc bro-pub-0.8a20/Active.cc bro-pub-0.8a20.orig/Active.cc *** bro-pub-0.8a20/Active.cc Fri Feb 7 16:58:35 2003 --- bro-pub-0.8a20.orig/Active.cc Thu Oct 31 23:29:27 2002 *************** *** 9,15 **** #include ! #include #include "Active.h" #include "util.h" --- 9,15 ---- #include ! #include #include "Active.h" #include "util.h" diff -rc bro-pub-0.8a20/Anon.h bro-pub-0.8a20.orig/Anon.h *** bro-pub-0.8a20/Anon.h Fri Feb 7 16:59:13 2003 --- bro-pub-0.8a20.orig/Anon.h Fri Oct 25 23:16:11 2002 *************** *** 12,18 **** #ifndef anon_h #define anon_h ! #include #include "net_util.h" enum anonymization_method_t { --- 12,18 ---- #ifndef anon_h #define anon_h ! #include #include "net_util.h" enum anonymization_method_t { diff -rc bro-pub-0.8a20/Debug.cc bro-pub-0.8a20.orig/Debug.cc *** bro-pub-0.8a20/Debug.cc Fri Feb 7 17:01:33 2003 --- bro-pub-0.8a20.orig/Debug.cc Sun Oct 27 12:51:50 2002 *************** *** 9,15 **** #include using namespace std; - #include #ifdef HAVE_READLINE #include --- 9,14 ---- diff -rc bro-pub-0.8a20/Type.h bro-pub-0.8a20.orig/Type.h *** bro-pub-0.8a20/Type.h Fri Feb 7 16:57:20 2003 --- bro-pub-0.8a20.orig/Type.h Fri Oct 18 11:08:23 2002 *************** *** 26,32 **** #include "Attr.h" #include "BroList.h" #include "Dict.h" ! #include // BRO types. --- 26,32 ---- #include "Attr.h" #include "BroList.h" #include "Dict.h" ! #include // BRO types. diff -rc bro-pub-0.8a20/builtin-func.y bro-pub-0.8a20.orig/builtin-func.y *** bro-pub-0.8a20/builtin-func.y Fri Feb 7 16:56:17 2003 --- bro-pub-0.8a20.orig/builtin-func.y Fri Oct 18 11:08:43 2002 *************** *** 1,5 **** %{ ! #include #include #include --- 1,5 ---- %{ ! #include #include #include From sommer at in.tum.de Sun Feb 9 09:30:51 2003 From: sommer at in.tum.de (Robin Sommer) Date: Sun, 9 Feb 2003 18:30:51 +0100 Subject: bro and FreeBSD 5.0 In-Reply-To: <20030208021407.GA2444@ncsa.uiuc.edu> References: <20030208021407.GA2444@ncsa.uiuc.edu> Message-ID: <20030209173051.GB19085@net.informatik.tu-muenchen.de> On Fri, Feb 07, 2003 at 20:14 -0600, Jon Dugan wrote: > DebugCmds.cc: In function `int find_all_matching_cmds(const std::string&, const > char**)': > DebugCmds.cc:164: invalid conversion from `const char*' to `unsigned int' Can you try the attached patch? There seems to be some incompatibility from gcc <3.0 to >= 3.0. 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 -------------- diff -uBbNr bro-pub-0.8a22/DebugCmds.cc bro-patched/DebugCmds.cc --- bro-pub-0.8a22/DebugCmds.cc Wed Nov 27 02:26:50 2002 +++ bro-patched/DebugCmds.cc Fri Jan 31 19:24:55 2003 @@ -161,7 +161,11 @@ for ( int j = 0; j < g_DebugCmdInfos[i]->NumNames(); ++j ) { const char* curr_name = g_DebugCmdInfos[i]->Names()[j]; +#if __GNUC__ == 3 + if ( prefix.compare(arglen, 0, curr_name) ) +#else if ( prefix.compare(curr_name, 0, arglen) ) +#endif continue; // If exact match, then only return that one. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20030209/387cf291/attachment.bin From vern at icir.org Sun Feb 9 09:46:52 2003 From: vern at icir.org (Vern Paxson) Date: Sun, 09 Feb 2003 09:46:52 -0800 Subject: bro and FreeBSD 5.0 In-Reply-To: Your message of Sun, 09 Feb 2003 18:30:51 +0100. Message-ID: <200302091746.h19Hkq3I097742@jaguar.icir.org> > Can you try the attached patch? There seems to be some incompatibility > from gcc <3.0 to >= 3.0. Umesh Shankar devised a cleaner fix, which I've appended. I'll get out a new "CURRENT" release within the coming week. Vern --- DebugCmds.cc.ORIG 2003/01/22 09:08:15 1.14 +++ DebugCmds.cc 2003/01/23 21:09:40 @@ -161,7 +161,7 @@ for ( int j = 0; j < g_DebugCmdInfos[i]->NumNames(); ++j ) { const char* curr_name = g_DebugCmdInfos[i]->Names()[j]; - if ( prefix.compare(0, arglen, curr_name) ) + if ( strncmp(curr_name, prefix.c_str(), arglen) ) continue; // If exact match, then only return that one. From vern at icir.org Wed Feb 12 23:08:48 2003 From: vern at icir.org (Vern Paxson) Date: Wed, 12 Feb 2003 23:08:48 -0800 Subject: useful *.bro files repository? In-Reply-To: Your message of Fri, 07 Feb 2003 14:36:10 EST. Message-ID: <200302130708.h1D78m3I073043@jaguar.icir.org> > I was wondering if there is (or SHOULD BE) a repository of useful *.bro > policies to use for different cases. Right now I am running with '@load > mt' and some other @load's which I semi-intelligently selected from the > policies dir, but I noticed there is a bunch of other fun bro files. Which > of them are useful and when? Well, it all depends on (1) your threat model, (2) how much load you can afford. I welcome suggestions about ways to organize these (and/or others that folks want to contribute) and experiences on which to use in what sorts of contexts. > Also, I understand that rules.bro is undocumented, but can I get ANY hints > on its functionality beyond what I can figure from looking at the files > itself...? You should hold off on that a bit. Robin has written a chapter for the Bro manual that describes the signature-matching, but the code is right now still somewhat in flux. (Also note that rules.bro has been renamed signatures.bro with the next Bro release.) This should be straightened out within a few weeks, though, as we're now ramping up at LBL to run with the signatures operationally. > BTW, I was also about to ask how to best collect and analyze alerts, but I > my have an answer to this one. Our product might soon collect Bro alerts > and report on them (in the context of other security event messages). Experiences/approaches in this regard will likewise be interesting to hear! Vern From anton at netForensics.com Fri Feb 21 13:47:54 2003 From: anton at netForensics.com (Anton Chuvakin, Ph.D.) Date: Fri, 21 Feb 2003 16:47:54 -0500 (EST) Subject: useful *.bro files repository? In-Reply-To: <200302130708.h1D78m3I073043@jaguar.icir.org> References: <200302130708.h1D78m3I073043@jaguar.icir.org> Message-ID: Vern and all, >Well, it all depends on (1) your threat model, (2) how much load you can >afford. I know :-) That is exactly why I asked. I was looking for ANY feedback on what others were doing with bro and received NOTHING. So I assume people are not really using it for any detection, but just as an educational tool (which is fine!). I continue to play with various polciies. Some combinations crash bro, some produce config parsing errors, some cause it to die a slow death, etc. Here is what I use now: @load mt @load http @load backdoor @load ssh @load stepping @load software @load smtp @load dns const interfaces += "eth1"; It works, doesn't detect much, some fun FTP attacks and weird RST packets got flagged. I want more :-) but some of the others I tried crash it. Best, -- Anton Chuvakin, Ph.D., GCIA Senior Security Analyst netForensics - http://www.netForensics.com 732-393-6071 From vern at icir.org Sat Feb 22 11:55:34 2003 From: vern at icir.org (Vern Paxson) Date: Sat, 22 Feb 2003 11:55:34 -0800 Subject: useful *.bro files repository? In-Reply-To: Your message of Fri, 21 Feb 2003 16:47:54 EST. Message-ID: <200302221955.h1MJtY3I056247@jaguar.icir.org> > I was looking for ANY feedback on > what others were doing with bro and received NOTHING. So I assume people > are not really using it for any detection, but just as an educational tool > (which is fine!). Well, LBL and UCB use it 24x7 for detection, quite effectively. I know some other sites are running it seriously, too. > I continue to play with various polciies. Some combinations crash bro, > some produce config parsing errors, some cause it to die a slow death, > etc. Rather than just stating these as generalities, please send along specifics so they can be investigated/fixed. (Feel free to do this privately if you want.) > Here is what I use now: Yep, that's what a number of our boxes use, except replace: > @load http with @load http-reply in order to pick up HTTP requests & replies. > It works, doesn't detect much, some fun FTP attacks and weird RST packets Do you know if things are indeed being missed? Vern