From vern at ee.lbl.gov Fri Apr 6 14:51:47 2001 From: vern at ee.lbl.gov (Vern Paxson) Date: Fri, 06 Apr 2001 14:51:47 PDT Subject: new Bro pre-release available - 0.7a61 Message-ID: <200104062151.f36LplV11779@daffy.ee.lbl.gov> A new Bro pre-release is now available from: ftp://ftp.ee.lbl.gov/.vp-bro-pub-0.7a61.tar.gz The most timely change is the addition of an NTP analyzer that can detect the new NTP remote root compromise attack. A summary of the changes with respect to 0.7a48: - An NTP analyzer has been added. See policy/ntp.bro for a corresponding policy file that detects the newly discovered NTP remote buffer overflow attack. - example-attacks/ is a new directory that contains trace files of attacks. Currently, there are just two to play with: bro -r example-attacks/ftp-site-exec.trace mt will run on a trace of a "site exec" overflow attack, and bro -r example-attacks/ntp-attack.trace mt ntp will run on an example of the NTP overflow. - The doc/ directory includes the postscript and HTML versions of the first draft of the Bro manual. - A new policy file, icmp.bro, has preliminary (and only partially developed) policy for analyzing ICMP. - The file libpcap.bufsize.patch includes the patch necessary on some systems to increase the maximum libpcap buffer size. - You can now use anonymous functions in &default expressions, so for example you can do: global foo: table[count] of string = { [1] = "1st", [2] = "2nd", [3] = "3rd", } &default = function(n: count): string { return fmt("%dth", n); }; and then referring to foo[5] will yield "5th". - There's now a "for" statement to iterate over the indices of a table or the members of a set: for ( i in foo ) for the above "foo" will iterate with i assigned to 1, 2, and 3; *but not in general in that order*. - The function contains_string() has been removed, and now you can instead use an expression like "bar" in "foobar" which will yield T. - The scan detection now has a mechanism for attempting to detect SYN flooding backscatter and flagging it as different from a stealth scan. - New event handlers: new_connection_contents() like new_connection(), but reassembles the stream so you can use set_content_files() to write it to a file udp_session_done() invoked when a UDP session (which is defined on a per-protocol basis; currently only for NTP) finishes. ntp_message() invoked for each NTP message - UDP processing now does accounting for detecting scans. - UDP processing now tracks numbers of requests/replies for sessions that support that notion. The connections are annotated by udp_session_done() with "[m,n]" for "m" requests and "n" replies, providing either m or n > 1. - New variable accessible from policy: watchdog_interval how often the watchdog should check for whether Bro is making internal progress - A bunch of functions no longer have a first argument of the current time; get it instead from network_time() if you need it: authentication_accepted authentication_rejected conn_weird conn_weird_addl flow_weird net_weird - A bunch of functions now return bool rather than int values: set_contents_file set_login_state set_record_packets skip_further_processing - The variable "hot_dests" has been renamed to "hot_dsts". - 111/tcp is now identified as "portmap" rather than "rpc". - Connections flagged as hot for some types of characteristics are now annotated with the reason associated with the decision. (I think a lot more of this is needed.) - Portmapper dumps are annotated with the results of the mapping. This will be streamlined in the future. - Vern From Roger_Knobbe at NAI.com Fri Apr 6 15:04:40 2001 From: Roger_Knobbe at NAI.com (Knobbe, Roger) Date: Fri, 6 Apr 2001 15:04:40 -0700 Subject: new Bro pre-release available - 0.7a61 Message-ID: <1D4F16D4D695D21186A300A0C9DCF983612327@dns-207.dhcp-83.nai.com> This is what I get c++ -I. -O -I../libpcap-0.4 -Ilinux-include -c Var.cc Var.cc: In function `void make_var (ID *, BroType *, init_class, Expr *, attr_list *, decl_type, int)': Var.cc:140: conditional expression between distinct pointer types `Expr *' and `BroType *' lacks a cast Var.cc:140: cannot convert `void *' to `BroObj *' in initialization make: *** [Var.o] Error 1 [burner at dns-102 bro-pub-0.7a61]$ c++ -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 20000731 (Red Hat Linux 7.0) [burner at dns-102 bro-pub-0.7a61]$ -----Original Message----- From: Vern Paxson [mailto:vern at ee.lbl.gov] Sent: Friday, April 06, 2001 2:52 PM To: bro at lbl.gov Subject: new Bro pre-release available - 0.7a61 A new Bro pre-release is now available from: ftp://ftp.ee.lbl.gov/.vp-bro-pub-0.7a61.tar.gz The most timely change is the addition of an NTP analyzer that can detect the new NTP remote root compromise attack. A summary of the changes with respect to 0.7a48: - An NTP analyzer has been added. See policy/ntp.bro for a corresponding policy file that detects the newly discovered NTP remote buffer overflow attack. - example-attacks/ is a new directory that contains trace files of attacks. Currently, there are just two to play with: bro -r example-attacks/ftp-site-exec.trace mt will run on a trace of a "site exec" overflow attack, and bro -r example-attacks/ntp-attack.trace mt ntp will run on an example of the NTP overflow. - The doc/ directory includes the postscript and HTML versions of the first draft of the Bro manual. - A new policy file, icmp.bro, has preliminary (and only partially developed) policy for analyzing ICMP. - The file libpcap.bufsize.patch includes the patch necessary on some systems to increase the maximum libpcap buffer size. - You can now use anonymous functions in &default expressions, so for example you can do: global foo: table[count] of string = { [1] = "1st", [2] = "2nd", [3] = "3rd", } &default = function(n: count): string { return fmt("%dth", n); }; and then referring to foo[5] will yield "5th". - There's now a "for" statement to iterate over the indices of a table or the members of a set: for ( i in foo ) for the above "foo" will iterate with i assigned to 1, 2, and 3; *but not in general in that order*. - The function contains_string() has been removed, and now you can instead use an expression like "bar" in "foobar" which will yield T. - The scan detection now has a mechanism for attempting to detect SYN flooding backscatter and flagging it as different from a stealth scan. - New event handlers: new_connection_contents() like new_connection(), but reassembles the stream so you can use set_content_files() to write it to a file udp_session_done() invoked when a UDP session (which is defined on a per-protocol basis; currently only for NTP) finishes. ntp_message() invoked for each NTP message - UDP processing now does accounting for detecting scans. - UDP processing now tracks numbers of requests/replies for sessions that support that notion. The connections are annotated by udp_session_done() with "[m,n]" for "m" requests and "n" replies, providing either m or n > 1. - New variable accessible from policy: watchdog_interval how often the watchdog should check for whether Bro is making internal progress - A bunch of functions no longer have a first argument of the current time; get it instead from network_time() if you need it: authentication_accepted authentication_rejected conn_weird conn_weird_addl flow_weird net_weird - A bunch of functions now return bool rather than int values: set_contents_file set_login_state set_record_packets skip_further_processing - The variable "hot_dests" has been renamed to "hot_dsts". - 111/tcp is now identified as "portmap" rather than "rpc". - Connections flagged as hot for some types of characteristics are now annotated with the reason associated with the decision. (I think a lot more of this is needed.) - Portmapper dumps are annotated with the results of the mapping. This will be streamlined in the future. - Vern From vern at ee.lbl.gov Fri Apr 6 16:05:31 2001 From: vern at ee.lbl.gov (Vern Paxson) Date: Fri, 06 Apr 2001 16:05:31 PDT Subject: new Bro pre-release available - 0.7a61 In-Reply-To: Your message of Fri, 06 Apr 2001 15:04:40 PDT. Message-ID: <200104062305.f36N5VC12285@daffy.ee.lbl.gov> > This is what I get > > c++ -I. -O -I../libpcap-0.4 -Ilinux-include -c Var.cc > Var.cc: In function `void make_var (ID *, BroType *, init_class, Expr > *, attr_list *, decl_type, int)': > Var.cc:140: conditional expression between distinct pointer types `Expr > *' and `BroType *' lacks a cast > Var.cc:140: cannot convert `void *' to `BroObj *' in initialization > make: *** [Var.o] Error 1 > [burner at dns-102 bro-pub-0.7a61]$ c++ -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs > gcc version 2.96 20000731 (Red Hat Linux 7.0) > [burner at dns-102 bro-pub-0.7a61]$ A fix for this is now available from: ftp://ftp.ee.lbl.gov/.vp-bro-pub-0.7a62.tar.gz - Vern From kerberos_007 at hotmail.com Sun Apr 8 17:27:08 2001 From: kerberos_007 at hotmail.com (kerberos kkk) Date: Sun, 08 Apr 2001 20:27:08 -0400 Subject: new Bro pre-release available - 0.7a61 Message-ID: Do this modification: it should work....at the line where the error occurs. BroObj* redef_obj = init ? (BroObj*)init : (BroObj*)t; cheers Ashley >From: "Knobbe, Roger" >To: "'Vern Paxson'" , bro at lbl.gov >Subject: RE: new Bro pre-release available - 0.7a61 >Date: Fri, 6 Apr 2001 15:04:40 -0700 > >This is what I get > >c++ -I. -O -I../libpcap-0.4 -Ilinux-include -c Var.cc >Var.cc: In function `void make_var (ID *, BroType *, init_class, Expr >*, attr_list *, decl_type, int)': >Var.cc:140: conditional expression between distinct pointer types `Expr >*' and `BroType *' lacks a cast >Var.cc:140: cannot convert `void *' to `BroObj *' in initialization >make: *** [Var.o] Error 1 >[burner at dns-102 bro-pub-0.7a61]$ c++ -v >Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs >gcc version 2.96 20000731 (Red Hat Linux 7.0) >[burner at dns-102 bro-pub-0.7a61]$ > > >-----Original Message----- >From: Vern Paxson [mailto:vern at ee.lbl.gov] >Sent: Friday, April 06, 2001 2:52 PM >To: bro at lbl.gov >Subject: new Bro pre-release available - 0.7a61 > > >A new Bro pre-release is now available from: > > ftp://ftp.ee.lbl.gov/.vp-bro-pub-0.7a61.tar.gz > >The most timely change is the addition of an NTP analyzer that can detect >the new NTP remote root compromise attack. > >A summary of the changes with respect to 0.7a48: > > - An NTP analyzer has been added. See policy/ntp.bro for a > corresponding policy file that detects the newly discovered > NTP remote buffer overflow attack. > > - example-attacks/ is a new directory that contains trace files > of attacks. Currently, there are just two to play with: > > bro -r example-attacks/ftp-site-exec.trace mt > > will run on a trace of a "site exec" overflow attack, and > > bro -r example-attacks/ntp-attack.trace mt ntp > > will run on an example of the NTP overflow. > > - The doc/ directory includes the postscript and HTML versions > of the first draft of the Bro manual. > > - A new policy file, icmp.bro, has preliminary (and only > partially developed) policy for analyzing ICMP. > > - The file libpcap.bufsize.patch includes the patch necessary > on some systems to increase the maximum libpcap buffer size. > > - You can now use anonymous functions in &default expressions, > so for example you can do: > > global foo: table[count] of string = { > [1] = "1st", [2] = "2nd", [3] = "3rd", > } &default = function(n: count): string { return fmt("%dth", >n); }; > > and then referring to foo[5] will yield "5th". > > - There's now a "for" statement to iterate over the indices of > a table or the members of a set: > > for ( i in foo ) > > for the above "foo" will iterate with i assigned to 1, 2, and 3; > *but not in general in that order*. > > - The function contains_string() has been removed, and now you > can instead use an expression like > > "bar" in "foobar" > > which will yield T. > > - The scan detection now has a mechanism for attempting to detect > SYN flooding backscatter and flagging it as different from a > stealth scan. > > - New event handlers: > > new_connection_contents() > like new_connection(), but reassembles the > stream so you can use set_content_files() to > write it to a file > > udp_session_done() > invoked when a UDP session (which is defined on > a per-protocol basis; currently only for NTP) > finishes. > > ntp_message() > invoked for each NTP message > > - UDP processing now does accounting for detecting scans. > > - UDP processing now tracks numbers of requests/replies for > sessions that support that notion. The connections are > annotated by udp_session_done() with "[m,n]" for "m" > requests and "n" replies, providing either m or n > 1. > > - New variable accessible from policy: > > watchdog_interval > how often the watchdog should check for whether > Bro is making internal progress > > - A bunch of functions no longer have a first argument of the > current time; get it instead from network_time() if you need it: > > authentication_accepted > authentication_rejected > conn_weird > conn_weird_addl > flow_weird > net_weird > > - A bunch of functions now return bool rather than int values: > > set_contents_file > set_login_state > set_record_packets > skip_further_processing > > - The variable "hot_dests" has been renamed to "hot_dsts". > > - 111/tcp is now identified as "portmap" rather than "rpc". > > - Connections flagged as hot for some types of characteristics > are now annotated with the reason associated with the > decision. (I think a lot more of this is needed.) > > - Portmapper dumps are annotated with the results of the mapping. > This will be streamlined in the future. > >- Vern _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From athomas at unity.ncsu.edu Mon Apr 9 13:36:29 2001 From: athomas at unity.ncsu.edu (Ashley Thomas) Date: Mon, 09 Apr 2001 16:36:29 -0400 Subject: Bro: effect of filter on speed/drops Message-ID: <3AD21D4D.B30A026C@unity.ncsu.edu> Hi, We run bro by specifying a filter like: 1. -f "tcp" or 2. -f "tcp or udp" Will one of these rules theoretically drop fewer packets than the other on heavy load ? Also will one execute faster than the other ? Put in another way if i specify -f "tcp", then libpcap filters only tcp filters from the lower layer, and if change the filter by specifying -f "tcp or udp" then libpcap filters both tcp and udp from the lower layer. Would this change slow down Bro a bit ? If libpcap is losing packets due to the enormous traffic in a network, can it be avoided by making the filter more specific ? thanks Ashley From vern at ee.lbl.gov Tue Apr 10 01:29:13 2001 From: vern at ee.lbl.gov (Vern Paxson) Date: Tue, 10 Apr 2001 01:29:13 PDT Subject: Bro: effect of filter on speed/drops In-Reply-To: Your message of Mon, 09 Apr 2001 16:36:29 PDT. Message-ID: <200104100829.f3A8TDA23275@daffy.ee.lbl.gov> > We run bro by specifying a filter like: > 1. -f "tcp" or > 2. -f "tcp or udp" > > Will one of these rules theoretically drop fewer packets than the other > on heavy load ? Also will one execute faster than the other ? Well, the first captures <= as many packets as the second, so it may be a bit better. *But* you usually shouldn't be using -f at all; the packets to capture are set by the "capture_filter" and "restrict_filter" policy variables, and if you look in the analyzers (e.g., FTP, login) in the policy/*.bro files, you'll see that they already specify tighter filters than the above. Either of the above will capture nearly all the traffic on the link; for high-speed monitoring, Bro instead relies on filtering out much of the traffic, capturing just TCP SYN/FIN/RST packets for general TCP analysis, and protocol-specific traffic (e.g., port 21/tcp for FTP) for the analyzers you instantiate. > If libpcap is losing packets due to the enormous traffic in a network, > can it be avoided by making the filter more specific ? Definitely! Vern From jdugan at ncsa.uiuc.edu Sat Apr 21 01:00:15 2001 From: jdugan at ncsa.uiuc.edu (Jon Dugan) Date: Sat, 21 Apr 2001 03:00:15 -0500 Subject: nit in scan.bro Message-ID: <20010421030015.A14970@ncsa.uiuc.edu> line 35 of scan.bro: const addl_web = { 81/tcp, 443/tcp, 8000/tcp, 8001/tcp, 8080/tcp, } &redef; unless i'm confused the first one should be 80/tcp, no? also, vern, do you want documentation submissions? i was going to fill in the sections about Building and Installing Bro (2.1.1) and Running Bro on network traffic (2.1.3). i noticed the source for the docs isn't included, so i can't make patches. Jon -- Jon Dugan | Senior Network Engineer, NCSA Network Development jdugan at ncsa.uiuc.edu | 57C CAB, 605 E Springfield, Champaign, IL 61820 217/244-7715 | http://www.ncsa.uiuc.edu/people/jdugan From jdugan at ncsa.uiuc.edu Sat Apr 21 15:07:27 2001 From: jdugan at ncsa.uiuc.edu (Jon Dugan) Date: Sat, 21 Apr 2001 17:07:27 -0500 Subject: nit in scan.bro In-Reply-To: <20010421030015.A14970@ncsa.uiuc.edu>; from jdugan@ncsa.uiuc.edu on Sat, Apr 21, 2001 at 03:00:15AM -0500 Message-ID: <20010421170727.A22273@ncsa.uiuc.edu> nevermind, i see that allow_services includes 80/tcp in hot.bro, which is in turn used in skip_outbound_services where addl_web is used. On Sat, Apr 21, 2001 at 03:00:15AM -0500, Jon Dugan wrote: > line 35 of scan.bro: > > const addl_web = { 81/tcp, 443/tcp, 8000/tcp, 8001/tcp, 8080/tcp, } &redef; > > unless i'm confused the first one should be 80/tcp, no? > > also, vern, do you want documentation submissions? i was going to fill in > the sections about Building and Installing Bro (2.1.1) and Running Bro on > network traffic (2.1.3). i noticed the source for the docs isn't included, > so i can't make patches. > > Jon > -- > Jon Dugan | Senior Network Engineer, NCSA Network Development > jdugan at ncsa.uiuc.edu | 57C CAB, 605 E Springfield, Champaign, IL 61820 > 217/244-7715 | http://www.ncsa.uiuc.edu/people/jdugan -- Jon Dugan | Senior Network Engineer, NCSA Network Development jdugan at ncsa.uiuc.edu | 57C CAB, 605 E Springfield, Champaign, IL 61820 217/244-7715 | http://www.ncsa.uiuc.edu/people/jdugan From vern at ee.lbl.gov Mon Apr 23 01:26:32 2001 From: vern at ee.lbl.gov (Vern Paxson) Date: Mon, 23 Apr 2001 01:26:32 PDT Subject: nit in scan.bro In-Reply-To: Your message of Sat, 21 Apr 2001 03:00:15 PDT. Message-ID: <200104230826.f3N8QWb11066@daffy.ee.lbl.gov> > also, vern, do you want documentation submissions? Yes, that would be terrific! Additions, corrections, annotations, questions, all very welcome. > i was going to fill in > the sections about Building and Installing Bro (2.1.1) and Running Bro on > network traffic (2.1.3). I've actually already written these, but didn't manage to get them out into the current on-line version of the docs. I'll do so shortly. > i noticed the source for the docs isn't included, > so i can't make patches. And I'll fix this in the next snapshot, too. Vern