From grue at merit.edu Mon Dec 7 08:35:13 1998 From: grue at merit.edu (Paul Howell) Date: Mon, 07 Dec 1998 11:35:13 -0500 Subject: icmp and bro Message-ID: <199812071635.LAA08975@merit.edu> Hello, Before I get too far into this, I wanted check and see if anyone else is actively working on adding ICMP to bro? I've started working on it and hope to be done pretty soon (famous last words!). Maybe I'm naive, but it doesn't look too hard. NetSessions::NextPacket() looks like the best place to start. I've got some very simple ICMP recognition code in place. I haven't looked at fragments or reassembly yet. Regards. < paul From vern at ee.lbl.gov Fri Dec 11 23:07:13 1998 From: vern at ee.lbl.gov (Vern Paxson) Date: Fri, 11 Dec 1998 23:07:13 PST Subject: icmp and bro In-Reply-To: Your message of Mon, 07 Dec 1998 11:35:13 EST. Message-ID: <199812120707.XAA11076@daffy.ee.lbl.gov> Sorry for the delay in replying - I've been away at the IETF all week. > Before I get too far into this, I wanted check and see if anyone > else is actively working on adding ICMP to bro? Others have mentioned it, but no one has actually signed up for doing this. > I've started working on it and hope to be done pretty soon (famous > last words!). Maybe I'm naive, but it doesn't look too hard. I'd expect it to not be particularly tricky - look forward to having this addition, it's frequently requested. > NetSessions::NextPacket() looks like the best place to start. Yes, that's where the demux happens. A key question is whether to introduce the notion of a ICMP "connection" (this is the model used for UDP, since most non-multicast UDP flows are bidirectional). With ICMP, this makes sense for ping, but not for the others that come to mind, though many of them fit into a model of ICMP-associated-with-other-connection, for example Unreachables associated with TCP or UDP connection initiations. So I think for now just tacking handling individual ICMP's without creating associated connection state or matching them to existing state is the way to go. A notion of connection state can be added later as needed; hopefully this will be fairly orthogonal to the rest of the ICMP analysis. > I've got some very simple ICMP recognition code in place. I haven't > looked at fragments or reassembly yet. You don't need to do those, there's a layer already in Bro that reassembles fragments and dispatches the recovered packet. Vern From grue at merit.edu Thu Dec 17 06:31:06 1998 From: grue at merit.edu (Paul Howell) Date: Thu, 17 Dec 1998 09:31:06 -0500 Subject: icmp and bro In-Reply-To: Your message of Fri, 11 Dec 1998 23:07:13 -0800. Message-ID: <199812171431.JAA15430@merit.edu> Vern Paxson writes: > Sorry for the delay in replying - I've been away at the IETF all week. > > > Before I get too far into this, I wanted check and see if anyone > > else is actively working on adding ICMP to bro? > > Others have mentioned it, but no one has actually signed up for doing this. Okay, well then I'll sign up. I haven't been working on this too much since I sent the original question, but I'll start now in earnst. > > NetSessions::NextPacket() looks like the best place to start. > > Yes, that's where the demux happens. A key question is whether to introduce > the notion of a ICMP "connection" (this is the model used for UDP, since most > non-multicast UDP flows are bidirectional). With ICMP, this makes sense for > ping, but not for the others that come to mind, though many of them fit into > a model of ICMP-associated-with-other-connection, for example Unreachables > associated with TCP or UDP connection initiations. > > So I think for now just tacking handling individual ICMP's without creating > associated connection state or matching them to existing state is the way > to go. A notion of connection state can be added later as needed; hopefully > this will be fairly orthogonal to the rest of the ICMP analysis. Gotcha. I leave out the notion of connection for now. > > I've got some very simple ICMP recognition code in place. I haven't > > looked at fragments or reassembly yet. > > You don't need to do those, there's a layer already in Bro that reassembles > fragments and dispatches the recovered packet. I assume you're referring to the fragment handling code which is called early on in NetSessions::NextPacket()? There isn't something before this that handles fragments, is there? Thanks. < paul From grue at merit.edu Thu Dec 17 06:32:56 1998 From: grue at merit.edu (Paul Howell) Date: Thu, 17 Dec 1998 09:32:56 -0500 Subject: shadow project and bro? Message-ID: <199812171432.JAA15465@merit.edu> Hi, I was curious if anyone has taken a look at replacing tcpdump with bro in the shadow ids package? It seems like a cool way to get a gui wrapped around bro. Thanks. < paul From grue at merit.edu Thu Dec 17 08:43:06 1998 From: grue at merit.edu (Paul Howell) Date: Thu, 17 Dec 1998 11:43:06 -0500 Subject: sanity check in bro Message-ID: <199812171643.LAA17856@merit.edu> Hi, I'm sure I'm missing something easy here, but I need a set of more experienced eyes to help me with this. In Sessions.cc, NetSessions::NextPacket(), there is: uint32 src_addr = uint32(ip->ip_src.s_addr); uint32 dst_addr = uint32(ip->ip_dst.s_addr); uint32 src_port, dst_port; // grue - print src/dst asap fprintf(stderr, "src %s dst %s\n", dotted_addr(src_addr), dotted_addr(dst_addr)); I added the fprintf more as a temporary debug line to see src/dst ip addresses. When I compile this and run it, I see the same ip address for source and destination. I would have expected to see different src/dst addresses, thinking that NetSessions::NextPacket() is called for every packet received. So what am I missing? Thanks. < paul From jni at aethis.be Thu Dec 17 09:08:22 1998 From: jni at aethis.be (Jean-Marc Nimal) Date: Thu, 17 Dec 1998 18:08:22 +0100 Subject: sanity check in bro Message-ID: <199812171708.SAA09320@aethis.be> > Hi, > > I'm sure I'm missing something easy here, but I need a set of > more experienced eyes to help me with this. I do not consider my eyes as so much experienced, but it seems to me to be a simple C/C++ problem. > In Sessions.cc, NetSessions::NextPacket(), there is: > > uint32 src_addr = uint32(ip->ip_src.s_addr); > uint32 dst_addr = uint32(ip->ip_dst.s_addr); > uint32 src_port, dst_port; > > // grue - print src/dst asap > fprintf(stderr, "src %s dst %s\n", dotted_addr(src_addr), > dotted_addr(dst_addr)); Here is it: dotted_aadr returns a pointer to the same static buffer. So you get the result of the second call. However, the function dotted_addr seems to include two static buffers (someone must have had the same problem ;-) so you probably can try: fprintf(stderr, "src %s dst %s\n", dotted_addr(src_addr,0), dotted_addr(dst_addr,1)); Where 0/1 selects the buffer (see Net.cc). Hopefully it helps; I'm not a C++ guru anyway, so maybe I'm completely wrong and off-topic :-) Jean-Marc Nimal Aethis sa/nv mailto:Jean-Marc.Nimal at aethis.be Hoping this goes to the list as this is my first attempt to post to it. From jni at aethis.be Thu Dec 17 09:27:19 1998 From: jni at aethis.be (Jean-Marc Nimal) Date: Thu, 17 Dec 1998 18:27:19 +0100 Subject: sanity check in bro Message-ID: <199812171727.SAA09406@aethis.be> Sorry all, (as expectable) I said something very stupid in my answer to Paul Howell. The integer you can specify in dotted_addr in Net.cc does of course not select an alternate buffer but an alternate format for the answer. So my proposed solution won't help at anything; you would still get twice the same address (in different formats though). But the problem is still buffer-related anyway, so you certainly figured out a soltuion already. Maybe we could change dotted_addr to implement two buffers, and toggle between both (like I foolishly thought it did)? I won't risk proposing some code this time... you got the point anyway. Jean-Marc Nimal Aethis sa/nv mailto:Jean-Marc.Nimal at aethis.be From jordan at Thinkbank.COM Thu Dec 17 09:59:03 1998 From: jordan at Thinkbank.COM (Jordan Hayes) Date: Thu, 17 Dec 98 09:59:03 PST Subject: sanity check in bro Message-ID: <9812171759.AA03905@blood.Thinkbank.COM> Feh, static buffers. Should probably pass in stack space for this anyway. I like to make a new typedef that's an array of the right size, then have people pass one in -- chance of passing in a NULL. Return the buffer that was passed in. Hey, then you're thread-safe too! :) /jordan From grue at merit.edu Thu Dec 17 10:16:39 1998 From: grue at merit.edu (Paul Howell) Date: Thu, 17 Dec 1998 13:16:39 -0500 Subject: sanity check in bro In-Reply-To: Your message of Thu, 17 Dec 1998 18:27:19 +0100. Message-ID: <199812171816.NAA20172@merit.edu> Jean-Marc Nimal writes: > [...deleted...] > But the problem is still buffer-related anyway, so you certainly figured > out a soltuion already. Maybe we could change dotted_addr to implement > two buffers, and toggle between both (like I foolishly thought it did)? Yup, that's it. Thanks. < Paul From vern at ee.lbl.gov Fri Dec 18 23:28:45 1998 From: vern at ee.lbl.gov (Vern Paxson) Date: Fri, 18 Dec 1998 23:28:45 PST Subject: icmp and bro In-Reply-To: Your message of Thu, 17 Dec 1998 09:31:06 EST. Message-ID: <199812190728.XAA07398@daffy.ee.lbl.gov> > > You don't need to do those, there's a layer already in Bro that reassembles > > fragments and dispatches the recovered packet. > > I assume you're referring to the fragment handling code which is > called early on in NetSessions::NextPacket()? Right, that's where it happens, all filtered packets go through here. Vern From iglesias at draco.acs.uci.edu Tue Dec 22 15:55:41 1998 From: iglesias at draco.acs.uci.edu (Mike Iglesias) Date: Tue, 22 Dec 1998 15:55:41 -0800 Subject: Problem compiling bro 0.4 on RedHat Linux 5.2 Message-ID: <199812222355.PAA05288@draco.acs.uci.edu> I'm trying to compile bro 0.4 on RedHat Linux 5.2, which has the egcs compilers installed by default: % c++ -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.90.29/specs gcc version egcs-2.90.29 980515 (egcs-1.0.3 release) When I try to compile bro, it stops on DNS.cc: % make c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -DVERSION="\"0.4\"" -c main.cc c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c parse.cc c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c scan.cc c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c util.cc c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c BroString.cc c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c CompHash.cc c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c Conn.cc c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c Desc.cc c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c Dict.cc c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c DNS.cc DNS.cc: In method `void DNS_Mgr::AddResult(class DNS_Request *, struct nb_dns_result *)': DNS.cc:688: parse error before `(' make: *** [DNS.o] Error 1 Here are the source lines in the area of the error (via cat -n DNS.cc) 683 return r; 684 } 685 686 void DNS_Mgr::AddResult(DNS_Request* dr, struct nb_dns_result* r) 687 { 688 hostent* h = (r && r->h_errno == 0) ? r->hostent : 0; 689 690 DNS_Mapping* new_dm; 691 DNS_Mapping* prev_dm; 692 int keep_prev = 0; 693 Anyone have any suggestions? I'm not very good with c++, so this is beyond my ability to fix. Mike Iglesias Internet: iglesias at draco.acs.uci.edu University of California, Irvine phone: 949-824-6926 Office of Academic Computing FAX: 949-824-2069 From PV500002 at exchange.Belgium.NCR.COM Wed Dec 23 06:20:38 1998 From: PV500002 at exchange.Belgium.NCR.COM (Verstraete, Patrick) Date: Wed, 23 Dec 1998 15:20:38 +0100 Subject: Problem compiling bro 0.4 on RedHat Linux 5.2 Message-ID: <1F520965ED73D2119C910000C02E6FFD09D9C3@SBEBRU04.Belgium.NCR.COM> Hi y'all, Mike, I think the easiest thing to do is to download version 0.5 including a (nice) port to Linux. I've installed bro (version 0.5a) on linux and on solaris machines Here follows some feedback about problems I've encountered. 1) the files doc/* are not installed in /usr/local/directory when using "make install" 2) directory /usr/local/bro should first be created before using "make install" (otherwise he copy all files to the file /usr/local/bro) 3) on Solaris 2.5.1, yacc doesn't want to compile parse.y A workaround was to install bison. yacc -dtv parse.y "parse.y", line 396: fatal: illegal rule: missing semicolon or | ? *** Error code 1 \\\|/// \\ ~ ~ // ( @ @ ) _________________oOOo-(_)-oOOo_________________________________ Patrick Verstraete NCR Belgium Tel: +32 2 761 14 09 Avenue M. Thiry, 79 Fax: +32 2 761 14 22 B-1200 Brussels Email: Patrick.Verstraete at belgium.ncr.com Belgium __________________Oooo.________________________________________ .oooO ( ) ( ) ) / \ ( (_/ \_) > -----Original Message----- > From: Mike Iglesias [SMTP:iglesias at draco.acs.uci.edu] > Sent: Wednesday, December 23, 1998 12:56 AM > To: bro at lbl.gov > Subject: Problem compiling bro 0.4 on RedHat Linux 5.2 > > I'm trying to compile bro 0.4 on RedHat Linux 5.2, which has the > egcs compilers installed by default: > > % c++ -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.90.29/specs > gcc version egcs-2.90.29 980515 (egcs-1.0.3 release) > > When I try to compile bro, it stops on DNS.cc: > > % make > c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -DVERSION="\"0.4\"" > -c main.cc > c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c parse.cc > c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c scan.cc > c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c util.cc > c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c BroString.cc > c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c CompHash.cc > c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c Conn.cc > c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c Desc.cc > c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c Dict.cc > c++ -I. -I../libpcap-0.4a6 -g -Wall -g -D__STDC__=2 -c DNS.cc > DNS.cc: In method `void DNS_Mgr::AddResult(class DNS_Request *, struct > nb_dns_result *)': > DNS.cc:688: parse error before `(' > make: *** [DNS.o] Error 1 > > > Here are the source lines in the area of the error (via cat -n DNS.cc) > 683 return r; > 684 } > 685 > 686 void DNS_Mgr::AddResult(DNS_Request* dr, struct nb_dns_result* r) > 687 { > 688 hostent* h = (r && r->h_errno == 0) ? r->hostent : 0; > 689 > 690 DNS_Mapping* new_dm; > 691 DNS_Mapping* prev_dm; > 692 int keep_prev = 0; > 693 > > Anyone have any suggestions? I'm not very good with c++, so this is > beyond > my ability to fix. > > > Mike Iglesias Internet: > iglesias at draco.acs.uci.edu > University of California, Irvine phone: 949-824-6926 > Office of Academic Computing FAX: 949-824-2069 From vern at ee.lbl.gov Wed Dec 30 00:26:22 1998 From: vern at ee.lbl.gov (Vern Paxson) Date: Wed, 30 Dec 1998 00:26:22 PST Subject: Problem compiling bro 0.4 on RedHat Linux 5.2 In-Reply-To: Your message of Wed, 23 Dec 1998 15:20:38 PST. Message-ID: <199812300826.AAA17500@daffy.ee.lbl.gov> > I've installed bro (version 0.5a) on linux and on solaris machines > Here follows some feedback about problems I've encountered. > > 1) the files doc/* are not installed in /usr/local/directory when using > "make install" > > 2) directory /usr/local/bro should first be created before using "make > install" (otherwise he copy all files to the file /usr/local/bro) > > 3) on Solaris 2.5.1, yacc doesn't want to compile parse.y > A workaround was to install bison. If you want to contribute patches for these (or at lesat for 1 & 2), that would be great. I don't ever formally install bro myself, so don't have occasion to use or debug these steps. Vern