From det2702 at mac.com Mon Oct 4 10:24:18 2004 From: det2702 at mac.com (det2702) Date: Mon, 4 Oct 2004 13:24:18 -0400 Subject: [Bro] LDAP Analyzer Message-ID: <3911427E-162A-11D9-9E9D-000A957017F2@mac.com> Greetings, I am successfully running BRO 0.90 in a test environment. Now I would like to write (and contribute to the BRO project) an LDAP analyzer. I have a customer that wants to monitor and protect their LDAP repository. What I am proposing is installing BRO specifically tuned and configured for LDAP analysis. Obviously, I'm new to BRO. I looked through the documentation and was not able to find anything on extending BRO's collection of analyzers. I'm especially interested on how to define event_handlers for custom policy scripts that leverage the LDAP analyzer. Can anybody vector me in the right direction? Thanks, Randy From rreitz at fnal.gov Mon Oct 4 11:03:51 2004 From: rreitz at fnal.gov (Randolph Reitz) Date: Mon, 04 Oct 2004 13:03:51 -0500 Subject: [Bro] Empty reports Message-ID: I have bro version 0.9a6 running. I see impressive sizes for files in /usr/local/bro/logs. For example... [rreitz at gumshoe rreitz]$ ls -l /usr/local/bro/logs/*04-10-03* -rw-r--r-- 1 bro wheel 88835 Oct 4 00:00 /usr/local/bro/logs/alarm.gumshoe.04-10-03_00.00.00 -rw-r--r-- 1 bro wheel 787345802 Oct 4 00:00 /usr/local/bro/logs/conn.gumshoe.04-10-03_00.00.00 -rw-r--r-- 1 bro wheel 3337706 Oct 4 00:00 /usr/local/bro/logs/ftp.gumshoe.04-10-03_00.00.00 -rw-r--r-- 1 bro wheel 4008666 Oct 4 00:00 /usr/local/bro/logs/http.gumshoe.04-10-03_00.00.00 -rw-r--r-- 1 bro wheel 28576 Oct 4 00:00 /usr/local/bro/logs/info.gumshoe.04-10-03_00.00.00 -rw-r--r-- 1 bro wheel 139345 Oct 4 00:00 /usr/local/bro/logs/notice.gumshoe.04-10-03_00.00.00 -rw-r--r-- 1 bro wheel 236 Oct 4 00:00 /usr/local/bro/logs/signatures.gumshoe.04-10-03_00.00.00 -rw-r--r-- 1 bro wheel 14411249 Oct 4 00:00 /usr/local/bro/logs/smtp.gumshoe.04-10-03_00.00.00 -rw-r--r-- 1 bro wheel 531 Oct 4 00:00 /usr/local/bro/logs/software.gumshoe.04-10-03_00.00.00 -rw-r--r-- 1 bro wheel 59967793 Oct 4 00:00 /usr/local/bro/logs/weird.gumshoe.04-10-03_00.00.00 -rw-r--r-- 1 bro wheel 0 Oct 3 00:00 /usr/local/bro/logs/worm.gumshoe.04-10-03_00.00.00 but the reports generated for 10/3 are empty. [rreitz at gumshoe rreitz]$ ls -lt /usr/local/bro/reports/local/ total 26 -rw-r--r-- 1 root wheel 1499 Oct 3 00:43 FNAL.1096781400.60653.rpt -rw-r--r-- 1 root wheel 1499 Oct 2 00:42 FNAL.1096695000.56628.rpt -rw-r--r-- 1 root wheel 1499 Oct 1 00:40 FNAL.1096608601.53259.rpt ... The report size of 1499 contains header/footer formatting only. For example... Site Report for FNAL, from 2004/10/02 00:30:00 to 2004/10/03 00:30:00 generated on Sun Oct 3 00:43:37 2004 ======================================================================== == Summary ======================================================================== == Incidents Likely Successful Unknown Likely Unsuccessful Scanning Hosts Successful 0 Unsuccessful 0 ======================================================================== == Incident Details ======================================================================== == No data to report ======================================================================== == Scans ======================================================================== == No data to report ======================================================================== == .... I need a clue where to look. Can /usr/local/bro/scrits/site-report.pl be run stand alone? Here is one configuration file I touched... [rreitz at gumshoe rreitz]$ cat /usr/local/bro/site/intern.bro # This file should describe your network configuration. # If your local network is a class C, and its network # address was 192.168.1.0 and a class B network # with address space 10.1.0.0. # Then you would put 192.168.1.0/24 and 10.1.0.0/16 into # this file, telling bro what your local networks are. @load site redef local_nets: set[subnet] = { 131.225.0.0/16 }; Thanks, Randy Reitz Computer Security Team From vern at icir.org Mon Oct 4 11:14:27 2004 From: vern at icir.org (Vern Paxson) Date: Mon, 04 Oct 2004 11:14:27 -0700 Subject: [Bro] Empty reports In-Reply-To: Your message of Mon, 04 Oct 2004 13:03:51 CDT. Message-ID: <200410041814.i94IERp3020332@jaguar.icir.org> Randy, the report stuff is not part of the public release at this point. I'll follow up with you privately regarding it. Vern From vern at icir.org Tue Oct 5 01:24:37 2004 From: vern at icir.org (Vern Paxson) Date: Tue, 05 Oct 2004 01:24:37 -0700 Subject: [Bro] LDAP Analyzer In-Reply-To: Your message of Mon, 04 Oct 2004 13:24:18 EDT. Message-ID: <200410050824.i958Obp3061622@jaguar.icir.org> An LDAP analyzer would be great to have. > Obviously, I'm new to BRO. I looked through the documentation and was > not able to find anything on extending BRO's collection of analyzers. Unfortunately, there isn't documentation for this yet. The way to go about it, though, is to identify an analyzer Bro already supports for a protocol that's similar to the one you want to do, and use the corresponding classes (in say HTTP.{h,cc} or DNS.{h,cc}, for example) as templates. > I'm especially interested on how to define event_handlers for custom > policy scripts that leverage the LDAP analyzer. See the file event.bif, which serves as the glue between the C++ of the event engine and the .bro policy script files. Vern From det2702 at mac.com Tue Oct 5 05:32:00 2004 From: det2702 at mac.com (det2702) Date: Tue, 5 Oct 2004 08:32:00 -0400 Subject: [Bro] LDAP Analyzer In-Reply-To: <200410050824.i958Obp3061622@jaguar.icir.org> References: <200410050824.i958Obp3061622@jaguar.icir.org> Message-ID: <8DFBF34E-16CA-11D9-AA58-000A957017F2@mac.com> Thanks. Scott Campbell sent some great pointers as well. I'll keep the group posted on my progress. Regards, Randy On Oct 5, 2004, at 4:24 AM, Vern Paxson wrote: > An LDAP analyzer would be great to have. > >> Obviously, I'm new to BRO. I looked through the documentation and was >> not able to find anything on extending BRO's collection of analyzers. > > Unfortunately, there isn't documentation for this yet. The way to go > about it, though, is to identify an analyzer Bro already supports for > a protocol that's similar to the one you want to do, and use the > corresponding classes (in say HTTP.{h,cc} or DNS.{h,cc}, for example) > as templates. > >> I'm especially interested on how to define event_handlers for custom >> policy scripts that leverage the LDAP analyzer. > > See the file event.bif, which serves as the glue between the C++ of the > event engine and the .bro policy script files. > > Vern > _______________________________________________ > Bro mailing list > Bro at ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From chema at cs.berkeley.edu Wed Oct 6 18:24:00 2004 From: chema at cs.berkeley.edu (=?iso-8859-1?q?Jos=E9_Mar=EDa_Gonz=E1lez?=) Date: Wed, 6 Oct 2004 18:24:00 -0700 Subject: [Bro] Skipping Connections versus Skipping Deliveries Message-ID: <200410061824.00512.chema@cs.berkeley.edu> Hi, I'm trying to understand the differences between Skipping Connections and Skipping Deliveries. My impression was that Skipping Connections would stop any further L4 processing of a connection. That's clearly the case in UDP, where NextPacket() first task is to check whether it must skip the connection. OTOH, this seems not true in TCP. I assume it's because Bro is interested in TCP headers independently of its interest in the L7 protocol. It's not the same case with UDP headers, as the latter are pretty much useless. Am I right? [1st Question] Skipping Deliveries (TCP_Contents.cc), OTH, controls whether L7 protocols should receive data lines or not. If you are not going to deliver lines to the L7 protocol, why would you be listening to the connection itself? My hunch is the same than before: It may be interesting to parse TCP contents anyway. The question is, then, shouldn't setting both endpoints of a connection to (skip_deliveries = 1) trigger SetSkip(1) ? [Question 2] Thanks for any help. -Chema From chema at cs.berkeley.edu Wed Oct 6 21:12:02 2004 From: chema at cs.berkeley.edu (=?iso-8859-1?q?Jos=E9_Mar=EDa_Gonz=E1lez?=) Date: Wed, 6 Oct 2004 21:12:02 -0700 Subject: [Bro] Bug (?) in TCP_Contents Message-ID: <200410062112.02317.chema@cs.berkeley.edu> Hi, When Bro sees an ACK for a packet before the packet itself (packet reordering), it considers that it already delivered the packet to the upper protocols, because it's acked. (see TCP_Contents.cc, line 272). I was wondering whether this is the intended behavior or it's a bug. -Chema From vern at icir.org Wed Oct 6 21:22:52 2004 From: vern at icir.org (Vern Paxson) Date: Wed, 06 Oct 2004 21:22:52 -0700 Subject: [Bro] Bug (?) in TCP_Contents In-Reply-To: Your message of Wed, 06 Oct 2004 21:12:02 PDT. Message-ID: <200410070422.i974Mqp3004184@jaguar.icir.org> > When Bro sees an ACK for a packet before the packet > itself (packet reordering), it considers that it already > delivered the packet to the upper protocols, because > it's acked. (see TCP_Contents.cc, line 272). > > I was wondering whether this is the intended behavior > or it's a bug. Note, that's *not* packet reordering in the sense of a network phenomenon. Causality requires that acknowledgments come *after* the packets they acknowledge! So it's intended behavior. It only becomes a problem in traces for which causality is broken. Unfortunately, this can happen due to reading from multiple NICs which have large buffers. If this is a problem in your environment, you can use packet_sort_window to sort the packets based on timestamps (assuming your NICs timestamp them correctly - if not, then all is lost ...). Vern From shaber at oit.ucsb.edu Sat Oct 9 01:36:44 2004 From: shaber at oit.ucsb.edu (Igor Shabaltas) Date: Sat, 9 Oct 2004 01:36:44 -0700 Subject: [Bro] gcc 3.4.2 and Bro compilation error References: <200410070422.i974Mqp3004184@jaguar.icir.org> Message-ID: <002c01c4addb$1c0e0360$a300a8c0@shaber> Greetings, bro-pub-0.9a4a$ make ... g++ -I. -I.. -Ilibedit -O -c main.cc In file included from PacketFilter.h:9, from Sessions.h:29, from RuleMatcher.h:12, from main.cc:54: PrefixTable.h:48: error: struct PrefixTable::iterator redeclared with different access main.cc: In function `int main(int, char**)': main.cc:319: error: array bound forbidden after parenthesized type-id main.cc:319: note: try removing the parentheses around the type-id *** Error code 1 bro-pub-0.9a4a$ gcc --version gcc (GCC) 3.4.2 [FreeBSD] 20040728 bro-pub-0.9a4a$ uname -v FreeBSD 5.3-BETA7 #0: Sat Oct 2 21:01:00 UTC 2004 --- Igor Shabaltas From doug.edey at virgin.net Sat Oct 9 02:23:17 2004 From: doug.edey at virgin.net (Douglas Edey) Date: Sat, 09 Oct 2004 10:23:17 +0100 Subject: [Bro] Make problems on Fedora Core 2 Message-ID: <1097313797.3429.8.camel@localhost.localdomain> Hi, I'm a student in the UK learning Software Engineering (1st Year) and I am learning Linux the hard way. I'm trying to installing bro and the ./configure process works fine, but when I try to make it just gives me this: [root at localhost bro-pub-0.8a87]# make g++ -I. -Ilibedit -O -Ilinux-include -c parse.cc y.tab.c: In function `int yyparse()': y.tab.c:1838: error: invalid types `int[int]' for array subscript make: *** [parse.o] Error 1 I was wondering if its something I've done wrong or something I missed. I apologise if I seem new to this because I am. Doug From rmkml at wanadoo.fr Sun Oct 10 10:12:09 2004 From: rmkml at wanadoo.fr (rmkml) Date: Sun, 10 Oct 2004 19:12:09 +0200 (CEST) Subject: [Bro] Memory leak pb ? Message-ID: Hi, Im use bro 09a5 on fbsd v4.10r Im runnning bro with statistics analyzer : 0.000000 Memory: total=7888K total_adj=0K malloced: 0K 0.000000 Run-time: user+sys=0.0 user=0.0 sys=0.0 real=0.0 0.000000 Conns: total=0 current=0/0 mem=0K avg=NaN table=0K connvals=0K 0.000000 Conns: tcp=0/0 udp=0/0 icmp=0/0 0.000000 TCP-States: Inact. Syn. SA Part. Est. Fin. Rst. 0.000000 TCP-States:Inact. 0.000000 TCP-States:Syn. 0.000000 TCP-States:SA 0.000000 TCP-States:Part. 0.000000 TCP-States:Est. 0.000000 TCP-States:Fin. 0.000000 TCP-States:Rst. 0.000000 Connections expired due to inactivity: 0 0.000000 Total reassembler data: 0K 0.000000 Timers: current=2 max=2 mem=0K lag=0.00s 0.000000 NetworkTimer = 1 0.000000 StatsTimer = 1 0.000000 Global_sizes > 100k: 0K 0.000000 Global_sizes total: 442K and after two days, 1097426765.058420 Memory: total=93660K total_adj=85772K malloced: 0K 1097426765.058420 Run-time: user+sys=2688.9 user=2591.6 sys=97.3 real=202407.8 1097426765.058420 Conns: total=901762 current=3980/3980 mem=5783K avg=1488.0 table=6176K connvals=3886K 1097426765.058420 Conns: tcp=3980/5145 udp=0/3189 icmp=0/0 1097426765.058420 TCP-States: Inact. Syn. SA Part. Est. Fin. Rst. 1097426765.058420 TCP-States:Inact. 10 676 1 1097426765.058420 TCP-States:Syn. 1097426765.058420 TCP-States:SA 1097426765.058420 TCP-States:Part. 164 1097426765.058420 TCP-States:Est. 860 2019 1 1097426765.058420 TCP-States:Fin. 21 46 1 1097426765.058420 TCP-States:Rst. 135 46 1097426765.058420 Connections expired due to inactivity: 136238 1097426765.058420 Total reassembler data: 670K 1097426765.058420 Timers: current=0 max=9526 mem=172K lag=0.01s 1097426765.058420 Global_sizes > 100k: 0K 1097426765.058420 num_distinct_low_ports = 616K (4376 entries) 1097426765.058420 scan_triples = 280K (2 entries) 1097426765.058420 active_conn = 3877K (3608 entries) 1097426765.058420 num_distinct_ports = 661K (4848 entries) 1097426765.058420 distinct_ports = 520K (5532 entries) 1097426765.058420 distinct_low_ports = 449K (4434 entries) 1097426765.058420 HTTP::http_sessions = 38216K (32508 entries) 1097426765.058420 Global_sizes total: 45268K Possible help me find why bro use 93660K ? Im use bro with analyzer : http-request http-reply dns statistics Regards Rmkml at Wanadoo.fr From chema at cs.berkeley.edu Sun Oct 10 18:10:45 2004 From: chema at cs.berkeley.edu (=?iso-8859-1?q?Jos=E9_Mar=EDa_Gonz=E1lez?=) Date: Sun, 10 Oct 2004 18:10:45 -0700 Subject: [Bro] Make problems on Fedora Core 2 In-Reply-To: <1097313797.3429.8.camel@localhost.localdomain> References: <1097313797.3429.8.camel@localhost.localdomain> Message-ID: <200410101810.45827.chema@cs.berkeley.edu> Doug, That's a well-known problem. http://crd.lbl.gov/mantis-bro/bug_view_page.php?bug_id=0000034 -Chema On Saturday 09 October 2004 02:23, Douglas Edey wrote: > Hi, > > I'm a student in the UK learning Software Engineering (1st Year) and I > am learning Linux the hard way. > > I'm trying to installing bro and the ./configure process works fine, but > when I try to make it just gives me this: > > [root at localhost bro-pub-0.8a87]# make > g++ -I. -Ilibedit -O -Ilinux-include -c parse.cc > y.tab.c: In function `int yyparse()': > y.tab.c:1838: error: invalid types `int[int]' for array subscript > make: *** [parse.o] Error 1 > > > I was wondering if its something I've done wrong or something I missed. > > I apologise if I seem new to this because I am. > > Doug > > _______________________________________________ > Bro mailing list > Bro at ICSI.Berkeley.EDU > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > > From christian at whoop.org Thu Oct 14 06:33:08 2004 From: christian at whoop.org (Christian Kreibich) Date: Thu, 14 Oct 2004 14:33:08 +0100 Subject: [Bro] Connection summaries question Message-ID: <1097760787.28283.348.camel@ghouls.cl.cam.ac.uk> Hi, are the following observations correct: - When Bro encounters a flow mid-stream and that flow gets shut down normally in the end, I see "SF" in connection summaries. - Also, it appears that when one port is well-known and the other is ephemeral, Bro assumes that the connection was established from the ephemeral to the well-known one. This is based on the following tiny trace: http://www.cl.cam.ac.uk/~cpk25/outback/http-single-midstream.trace I'm asking because I'm selecting flows from a trace based on this output and the semantics matter. Intuitively I would have assumed that SF is only printed for flows seen in their entirety. OTH, however, seems to stand for just mid-stream data with neither handshake nor teardown seen, and there doesn't seem to be a symbol for flows seen from mid-stream to the end? Thanks, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From ManuX at rstack.org Tue Oct 19 12:02:32 2004 From: ManuX at rstack.org (manu) Date: Tue, 19 Oct 2004 21:02:32 +0200 Subject: [Bro] Rsh analyzer Message-ID: <417564C8.2040007@rstack.org> Here is a trivial patch providing the current bro release for a Rsh analyser. It used to allow the detection of funny behaviors like local/remote username mismatch, interactive shell in rsh, etc. Of few interests now but as it still was in the wish list... Manu -------------- next part -------------- A non-text attachment was scrubbed... Name: bro-pub-0.9a4a-rsh.diff Type: text/x-patch Size: 14138 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20041019/7ba7c303/attachment.bin From zwei03 at citiz.net Thu Oct 21 18:56:10 2004 From: zwei03 at citiz.net (cliff) Date: Fri, 22 Oct 2004 09:56:10 +0800 Subject: [Bro] about "reassembles IP fragments" Message-ID: <000501c4b7da$5681b0b0$086f6fa8@lib008> Hi all, In Vern's paper,bro:a system for detecting network intruders in real-time,there are the following sentences: "The resulting filtered packet stream is then handed up to the next layer, the Bro ``event engine.'' This layer first performs several integrity checks to assure that the packet headers are well-formed, including verifying the IP header checksum. If these checks fail, then Bro generates an event indicating the problem and discards the packet. It is also at this point that Bro reassembles IP fragments so it can then analyze complete IP datagrams." Howerver,I can't find the implementation detail from source code,i.e."verifying the IP header checksum" and "reassembles IP fragments". I wish get your help.Thanks a lot! Best Regards, Cliff From sommer at in.tum.de Fri Oct 22 01:16:56 2004 From: sommer at in.tum.de (Robin Sommer) Date: Fri, 22 Oct 2004 10:16:56 +0200 Subject: [Bro] about "reassembles IP fragments" In-Reply-To: <000501c4b7da$5681b0b0$086f6fa8@lib008> References: <000501c4b7da$5681b0b0$086f6fa8@lib008> Message-ID: <20041022081656.GB23250@net.informatik.tu-muenchen.de> On Fri, Oct 22, 2004 at 09:56 +0800, cliff wrote: > Howerver,I can't find the implementation detail from source > code,i.e."verifying the IP header checksum" and "reassembles IP > fragments". The fragment reassembler is in Frag.*. Checksums are verified at multiple locations; try grepping for "_checksum" 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 Fri Oct 22 03:24:51 2004 From: christian at whoop.org (Christian Kreibich) Date: Fri, 22 Oct 2004 11:24:51 +0100 Subject: [Bro] about "reassembles IP fragments" In-Reply-To: <000501c4b7da$5681b0b0$086f6fa8@lib008> References: <000501c4b7da$5681b0b0$086f6fa8@lib008> Message-ID: <1098440691.12201.8.camel@ghouls.cl.cam.ac.uk> Hi, On Fri, 2004-10-22 at 02:56, cliff wrote: > Hi all, > In Vern's paper,bro:a system for detecting network intruders in real-time,there are the following sentences: > "The resulting filtered packet stream is then handed up to the next layer, the Bro ``event engine.'' This layer first performs several integrity checks to assure that the packet headers are well-formed, including verifying the IP header checksum. If these checks fail, then Bro generates an event indicating the problem and discards the packet. It is also at this point that Bro reassembles IP fragments so it can then analyze complete IP datagrams." > Howerver,I can't find the implementation detail from source code,i.e."verifying the IP header checksum" and "reassembles IP fragments". > I wish get your help.Thanks a lot! for IP checksumming, check Sessions.cc around 261 (assuming a 0.9a4a tree). "grep -i checksum *.cc" also helps :) Fragment reassembly is done in Frag.cc. Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From christian at whoop.org Fri Oct 22 03:29:42 2004 From: christian at whoop.org (Christian Kreibich) Date: Fri, 22 Oct 2004 11:29:42 +0100 Subject: [Bro] about "reassembles IP fragments" In-Reply-To: <20041022081656.GB23250@net.informatik.tu-muenchen.de> References: <000501c4b7da$5681b0b0$086f6fa8@lib008> <20041022081656.GB23250@net.informatik.tu-muenchen.de> Message-ID: <1098440982.12201.14.camel@ghouls.cl.cam.ac.uk> On Fri, 2004-10-22 at 09:16, Robin Sommer wrote: > On Fri, Oct 22, 2004 at 09:56 +0800, cliff wrote: > > > Howerver,I can't find the implementation detail from source > > code,i.e."verifying the IP header checksum" and "reassembles IP > > fragments". > > The fragment reassembler is in Frag.*. Checksums are verified at > multiple locations; try grepping for "_checksum" Hrm. Maybe I should learn to read my mails before replying :) Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From zwei03 at citiz.net Sat Oct 23 18:54:55 2004 From: zwei03 at citiz.net (cliff) Date: Sun, 24 Oct 2004 09:54:55 +0800 Subject: [Bro] about "*.bif files" Message-ID: <001001c4b96c$7fcb1a40$046f6fa8@lib004> Hi all, At first,I must thanks a lot to Christian,Robin and so on for your help. Well,a another question:) There are many *.bif files in src directory.I don't know the format and use of these files.Please explain it as possible as detailed.Thanks! Best Regards, Cliff From rpang at CS.Princeton.EDU Sun Oct 24 00:59:09 2004 From: rpang at CS.Princeton.EDU (Ruoming Pang) Date: Sun, 24 Oct 2004 03:59:09 -0400 Subject: [Bro] about "*.bif files" In-Reply-To: <001001c4b96c$7fcb1a40$046f6fa8@lib004> References: <001001c4b96c$7fcb1a40$046f6fa8@lib004> Message-ID: <96167B8E-2592-11D9-A4B1-000D9335A7D8@cs.princeton.edu> > Well,a another question:) There are many *.bif files in src > directory.I don't know the format and use of these files.Please > explain it as possible as detailed.Thanks! Cliff, The .bif files contain code of Bro built-in functions ("bif" stands for "built-in function"). Built-in functions are implemented in C++ and can be called by policy scripts. The bif compiler (bifcl) takes a .bif file and generate the corresponding C++ segments and Bro language declarations, so that each function only needs be written once in a .bif file and the actual C++/Bro code will be automatically generated. For example, below is the bif code for function byte_len (in bro.bif): function byte_len%(s: string%): count %{ return new Val(s->Len(), TYPE_COUNT); %} Note that it first starts with a function prototype in Bro language (but with %( and %)), and between %{ and %} is the C++ implementation of the function. It is translated into the following four pieces by bifcl: 1) A Bro prototype in policy/bro.bif.bro (which is loaded in bro.init): global byte_len: function(s: string): count; 2) A C++ function prototype in bro.bif.func_h: extern Val* bro_byte_len(val_list*); 3) A C++ function implementation in bro.bif.func_def (included in Func.cc) Val* bro_byte_len(val_list* BiF_ARGS) #line 432 "bro.bif" { if ( BiF_ARGS->length() != 1 ) { run_time("byte_len() takes exactly 1 argument(s)"); return 0; } BroString* s = (BroString*) ((*BiF_ARGS)[0]->AsString()); #line 432 "bro.bif" return new Val(s->Len(), TYPE_COUNT); } // end of byte_len 4) Initialization code that associates the C++ function with the name "byte_len" in bro.bif.func_init (also included in Func.cc): extern Val* bro_byte_len(val_list*); (void) new BuiltinFunc(bro_byte_len, "byte_len", 0); While the bif compiler was originally written for built-in functions only, it was later extended to declare events (in event.bif) and constants (in const.bif) as well. Three additional files are generated for these declarations (.netvar_h, .netvar_def and .netvar_init). How it works is quite straightforward once you take a look at these files (e.g. for event.bif). I hope it helps. Please feel free to ask if you have further questions. Ruoming From zwei03 at citiz.net Sun Oct 24 19:56:10 2004 From: zwei03 at citiz.net (zwei03 at citiz.net) Date: Mon, 25 Oct 2004 10:56:10 +0800 (CST) Subject: [Bro] Re: about "*.bif files" Message-ID: <1098672970948.5852.app5.Naesasoft.PXWDB1YR> Hi Ruoming, Very thank you for so detailed explanation.:) Are you one of the developers of *Bro*? Have you the plan to publicize your design details on the web http://www.icir.org/twiki/bin/view/Bro/WebHome? Thanks, Cliff -------------------------------------------------- ?????????? http://happy.online.sh.cn/features/anniversary/index.htm ???????????IQ http://happy.online.sh.cn/features/anniversary/zhiduoshao/index.htm ??????????? http://sh.online.sh.cn -------------------------------------------------- From rpang at CS.Princeton.EDU Mon Oct 25 13:58:38 2004 From: rpang at CS.Princeton.EDU (Ruoming Pang) Date: Mon, 25 Oct 2004 16:58:38 -0400 Subject: [Bro] Re: about "*.bif files" In-Reply-To: <1098672970948.5852.app5.Naesasoft.PXWDB1YR> References: <1098672970948.5852.app5.Naesasoft.PXWDB1YR> Message-ID: > Very thank you for so detailed explanation.:) Cliff, My pleasure -- actually thanks for asking the question. I should have documented the bif compiler long time ago. > Have you the plan to publicize your design details on the web > http://www.icir.org/twiki/bin/view/Bro/WebHome? Christian have put the description in my email at: http://www.icir.org/twiki/bin/view/Bro/BroBuiltInFunctions. I will add more to it if any further question arises from the list. Ruoming From vern at icir.org Thu Oct 28 18:55:37 2004 From: vern at icir.org (Vern Paxson) Date: Thu, 28 Oct 2004 18:55:37 -0700 Subject: [Bro] Rsh analyzer In-Reply-To: Your message of Tue, 19 Oct 2004 21:02:32 +0200. Message-ID: <200410290155.i9T1tbA2005801@jaguar.icir.org> > Here is a trivial patch providing the current bro release for a Rsh > analyser. > It used to allow the detection of funny behaviors like local/remote > username mismatch, interactive shell in rsh, etc. Thanks!, I've integrated this and will include it in either the next release (out quite soon) or the one after. Vern