From vern at icir.org Mon Nov 1 15:00:02 2004 From: vern at icir.org (Vern Paxson) Date: Mon, 01 Nov 2004 15:00:02 -0800 Subject: [Bro] new Bro CURRENT release (0.9a7) Message-ID: <200411012300.iA1N02A2082800@jaguar.icir.org> A new CURRENT release, 0.9a7, is now available from: ftp://ftp.ee.lbl.gov/bro-0.9-current.tar.gz This release includes a number of changes (appended), with one major one that will break backwards compatibility being the renaming of "log" to "alarm" and "alert" to "notice". This is a fairly stable snapshot prior to another release forthcoming soon that will have a number of further changes, including some new log file formats. Vern -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0.9a7 Mon Nov 1 13:21:05 PST 2004 - New terminology: o We've found that the term "log" has been too overloaded, sometimes meaning "something to record for audit purposes" and other times meaning "something worthy of getting the operator's attention right now, for example via syslog". We are now using "log" to only refer to the first of these, and refer to the second as "alarm". o We've found that "alert" (and the ALERT() function, etc) is likewise confusing. Some expect it to mean something alarm-worthy (to use the new name from the previous item), while others expect it to mean the output from a sensor, which might not be worth getting the operator's attention. We are now using "notice" to refer to what had previously been called "alert". So, for example, rather than call ALERT() you call NOTICE() to enter something into the I've-seen-something- maybe-it's-worth-an-alarm framework. The first field associated with such a call was $alert, which is now $note. These notifications are logged to notice.$BRO_LOG_SUFFIX rather than "alert."... These changes show up in many places in the policy scripts. Some globals log_XXX are now alarm_XXX or notice_XXX. However, uses of "log" that refer to "something to record for audit purposes" remain using that name. - Bro now uses the "automake" suite of tools for its configuration (Jason Lee). This includes major reworking of its Makefile's and configuration/installation scripts. - Bro now flags event handlers that are never invoked (Umesh Shankar). This catches typos like: event bro_initt() { ... } - The scripts directory now includes scripts for generating nightly reports (Roger Winslow). Note that these are not presently a supported part of the public Bro distribution, but will become so in the not-too-distant future. - policy/brolite.bro contains a first version of the "Bro Lite" configuration (Scott Campbell, Roger Winslow, et al). This also is not presently supported for the public Bro distribution, but will become so. - Major overhaul of the internal serialization framework (Robin Sommer). Some more changes are forthcoming, though not on this scale. - Changed packet capture/drop statistics to (1) explicitly track received packets, (2) work better under Linux, (3) report link counts when available (Robin Sommer). The net_stats record field "interface_drops" has been renamed "pkts_link". It reports the number of packets captured by the NIC (if available), rather than the number dropped by the NIC (which never actually worked, anyway). - The DNS analysis has been extended to deal with TSIG and to better deal with EDNS0 records, and its overall structure reworked somewhat (Scott Campbell & Roger Winslow). The scripts in dns.bro are now inside "module DNS" scope. - Improved logging of ICMP flows (Scott Campbell). This includes the addition of a "len" field in icmp_conn. Some significant additional changes/improvements to ICMP processing will be coming very soon. - The Bro README and "quick start" documentation has been updated (Brian Tierney and Jim Rothfuss). - Some significant state-holding problems in the presence of packet filtering or packet drops have been fixed. - You can now instruct the signature engine to constrain the number of regular expressions it groups together into a single matcher using the new script variable "sig_max_group_size" (Robin Sommer). This can result in significant memory savings for large sets of signatures. It can increase the CPU processing required; however, in our testing so far this does not appear to be the case. - The signature engine now provides better location information in its error messages (Robin Sommer). - statistics.bro has been renamed profiling.bro. Along with this change, the following script variables have been renamed: do_statistics => do_profiling statistics_file => profiling_file statistics_interval => profiling_interval - A new script, stats.bro, can be included to generate light-weight running statistics on memory and CPU use. - A new script, print-sig-states.bro, can be included to generate periodic dumps of signature-matching statistics (Robin Sommer). - The connect_clear()/connect_ssl() built-ins have been replaced by a single connect() function (Robin Sommer). - Remote Bro's (more generally, remote event sources) are now represented in policy scripts using the new "event_peer" type rather than as an addr/port pair, and get_event_source() has been renamed get_event_peer() (Robin Sommer). The new function get_local_event_peer() returns an event_peer corresponding to the local Bro. - The new script remote-print.bro can be used to print all events received from remote sources (Robin Sommer). - When you call send_state(), an event finished_send_state() is now generated when all of the state has been sent (Robin Sommer). - If you define a handler for the new print_hook() event, then it will be invoked every time a "print" statement executes (Robin Sommer). - The -g flag no longer takes a directory as an argument, but always uses the .state directory (Robin Sommer). - The new -I flag prints the value of a given identifier and exits (Robin Sommer). This flag may go away in the future. For now, its role is that it prints timestamps of things like table elements, which are no longer printed by a regular "print" statement. - If a connection proceeds as SYN ->, <- RST, RST ->, this is now reported as a regular rejected ("REJ") connection, rather than one reset by the originator ("RSTO"). - The TCP analyzer now attempts to detect connections for which one side's packets are being filtered out. It does this using two C++ variables (not presently accessible at the script level), const int max_initial_window = 4096; const int max_above_hole_without_any_acks = 4096; If more than max_initial_window data has been sent by one side and no ACKs have been seen by the other side, then it's assumed that no ACKs will ever show up, and the buffer for the data should be reclaimed immediately after it's reassembled. max_above_hole_without_any_acks plays a similar role, but for the case when measurement drops have lead to Bro holding data for a sender for which it will never see an ACK (which would be an "ACK above hole"), so it should give up on buffering it. - A portability bug in Bro's parser code has been fixed (Jason Lee). - STARTTLS for SMTP now causes the SMTP session to be ignored, rather than generating a slew of error messages because the session becomes unparseable. - Bro's "watchdog" handler is now less prone to crashing due to using non-reentrant library calls (Jason Lee). - Better error message when reading an input file encounters an error. - adtrace now prints its usage when invoked without the required arguments (Jason Lee). - A bug in using recursive script functions has been fixed. - A bunch of whitespace/code layout tweaks. From mallman at icir.org Mon Nov 1 20:11:26 2004 From: mallman at icir.org (Mark Allman) Date: Mon, 01 Nov 2004 23:11:26 -0500 Subject: [Bro] test; please ignore Message-ID: <20041102041126.D3C601F6866@lawyers.icir.org> mailing list setup test, sorry for the chud -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20041101/901ca127/attachment.bin From mallman at icir.org Mon Nov 1 20:56:06 2004 From: mallman at icir.org (Mark Allman) Date: Mon, 01 Nov 2004 23:56:06 -0500 Subject: [Bro] another test; sorry - please ignore Message-ID: <20041102045607.10F1C1F697C@lawyers.icir.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20041101/ff1c02d8/attachment.bin From bpatters at fit.edu Wed Nov 3 12:25:19 2004 From: bpatters at fit.edu (Bryan Patterson) Date: Wed, 3 Nov 2004 15:25:19 -0500 (EST) Subject: [Bro] comparing Bro Message-ID: <3805.137.237.32.170.1099513519.squirrel@137.237.32.170> Hello, I am researching Bro for a school project at Florida Tech. We are required to compare the output of Bro and Snort on traffic captures. I know about the "snort2bro" command. I was wondering if anyone could give me a couple of examples of the command-line syntax for the instruction. I am using Bro 0.8 with the following command: > bro -r capture.tcpdump mt.bro which triggers the following bro alerts - 'alert', 'ftp', 'log' and 'weird' for snort2bro: > snort2bro capture.tcpdump I would like to analyze how Short handles these 4 alerts. Thanks, Bryan Melbourne, FL From rmkml at wanadoo.fr Wed Nov 3 16:47:26 2004 From: rmkml at wanadoo.fr (rmkml) Date: Thu, 4 Nov 2004 01:47:26 +0100 (CET) Subject: [Bro] WeirdActivity unknown_DNS_RR_type question In-Reply-To: References: <200409172334.i8HNYBp3047754@jaguar.icir.org> Message-ID: Hi list, for information, last bro 09a7 version, always event AAAA to "unknown_DNS_RR_type" weird event. Regards Rmkml at Wanadoo.fr > On Fri, 17 Sep 2004, Vern Paxson wrote: > >> Date: Fri, 17 Sep 2004 16:34:11 -0700 >> From: Vern Paxson >> To: rmkml >> Cc: bro at bro-ids.org >> Subject: Re: [Bro] WeirdActivity unknown_DNS_RR_type question >> >>> AAAA is unknown rr type ? >> >> Per CHANGES: >> >> ... DNS analyzer doesn't understand AAAA yet ... >> >> However, Roger Winslow & Scott Campbell have recently extended the DNS >> analysis, and one of the several things they added was AAAA support. >> So this will work in the next release. ------------ >> >> Vern From rmkml at wanadoo.fr Wed Nov 3 16:56:39 2004 From: rmkml at wanadoo.fr (rmkml) Date: Thu, 4 Nov 2004 01:56:39 +0100 (CET) Subject: [Bro] not detect {big} scan with scan analyser In-Reply-To: References: Message-ID: Hi list, sorry for noise, but last bro version 09a7 not detect any {BIG} scan .... Regards Rmkml at Wanadoo.fr On Sat, 11 Sep 2004, rmkml wrote: > Date: Sat, 11 Sep 2004 21:49:48 +0200 (CEST) > From: rmkml > To: bro at bro-ids.org > Subject: [Bro] not detect {big} scan with scan analyser > > Hi, > > Im use bro 09a[3-4-5] on freebsd v4.10R, > > bro not detect this scan, (joigned pcap/gz file) > > with default policy, > > but in conn.log file : > > 1085375478.746540 0.000008 128.173.231.31 62.23.34.167 smtp 3618 25 tcp ? ? > REJ X > 1085375479.331791 0.000003 128.173.231.31 62.23.34.167 smtp 3618 25 tcp ? ? > REJ X > 1085375481.138096 ? 128.173.231.31 62.23.34.162 ftp 3565 21 tcp ? ? S0 X > 1085375481.138064 ? 128.173.231.31 62.23.34.162 http 3566 80 tcp ? ? S0 X > 1085375481.138104 ? 128.173.231.31 62.23.34.162 dns 3567 53 tcp ? ? S0 X > 1085375481.138047 ? 128.173.231.31 62.23.34.162 smtp 3568 25 tcp ? ? S0 X > 1085375481.138072 ? 128.173.231.31 62.23.34.162 finger 3569 79 tcp ? ? S0 X > ... > > $ export BROPATH=/c/confL/policy > $ export BRO_DNS_FAKE=1 # disable dns lookup > $ /usr/local/bin/bro09a5_nodns_micro -r scantcp-viginia_edu.tcpdump bro.init > mt > -> scan anlyser in mt.bro (@load scan) > > Possible help me ? > > Regards > > Rmkml at Wanadoo.fr From rmkml at wanadoo.fr Thu Nov 4 16:09:14 2004 From: rmkml at wanadoo.fr (rmkml) Date: Fri, 5 Nov 2004 01:09:14 +0100 (CET) Subject: [Bro] Memory pb on 09a7 ? Message-ID: Hi, Im use last bro 09a7 but bro memory use : VSZ RSS CMD 96368 90568 /usr/local/bin/bro09a7_micro -i fxp1 bro.init mt http-request http-reply profiling dns look prof.log : 0.000000 ------------------------ 0.000000 Command line: /usr/local/bin/bro09a7_micro -i fxp1 bro.init mt http-request http-reply profiling dns 0.000000 ------------------------ 0.000000 Memory: total=9656K 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 ProfileTimer = 1 0.000000 Global_sizes > 100k: 0K 0.000000 Global_sizes total: 461K 1099436883.565372 ------------------------ ... 1099602683.735772 ------------------------ 1099602683.735772 Memory: total=90588K total_adj=80932K malloced: 0K 1099602683.735772 Run-time: user+sys=5120.8 user=4992.5 sys=128.3 real=165801.2 1099602683.735772 Conns: total=1838447 current=25325/25325 mem=37206K avg=1504.4 table=38701K connvals=25386K 1099602683.735772 Conns: tcp=25135/31084 udp=190/2502 icmp=0/0 1099602683.735772 TCP-States: Inact. Syn. SA Part. Est. Fin. Rst. 1099602683.735772 TCP-States:Inact. 10 1011 1 1099602683.735772 TCP-States:Syn. 117 7 1 1099602683.735772 TCP-States:SA 1099602683.735772 TCP-States:Part. 8 6 1 1099602683.735772 TCP-States:Est. 17384 5617 2 1099602683.735772 TCP-States:Fin. 2 860 41 23 1099602683.735772 TCP-States:Rst. 4 40 1099602683.735772 Connections expired due to inactivity: 1033831 1099602683.735772 Total reassembler data: 203K 1099602683.735772 Timers: current=37759 max=62252 mem=3884K lag=0.00s 1099602683.735772 ConnectionDeleteTimer = 70 1099602683.735772 ConnectionInactivityTimer = 190 1099602683.735772 DNSExpireTimer = 190 1099602683.735772 NetworkTimer = 1 1099602683.735772 ProfileTimer = 1 1099602683.735772 ScheduleTimer = 5124 1099602683.735772 TCPConnectionAttemptTimer = 594 1099602683.735772 TCPConnectionExpireTimer = 31558 1099602683.735772 TCPConnectionResetTimer = 32 1099602683.735772 Global_sizes > 100k: 0K 1099602683.735772 DNS::dns_sessions = 366K (291 entries) 1099602683.735772 distinct_low_ports = 604K (6721 entries) 1099602683.735772 distinct_ports = 656K (7499 entries) 1099602683.735772 FTP::ftp_data_expected = 99680K (1075 entries) 1099602683.735772 FTP::ftp_sessions = 118K (5 entries) 1099602683.735772 DNS::consistency_table = 1887K (4833 entries) 1099602683.735772 num_distinct_low_ports = 855K (6608 entries) 1099602683.735772 active_conn = 27983K (25213 entries) 1099602683.735772 HTTP::http_sessions = 2451K (2153 entries) 1099602683.735772 num_distinct_ports = 887K (6907 entries) 1099602683.735772 DNS::dns_history = 2533K (4833 entries) 1099602683.735772 Global_sizes total: 138583K Possible help me ? Regards Rmkml at Wanadoo.fr From anton at netForensics.com Thu Nov 4 14:54:35 2004 From: anton at netForensics.com (Anton Chuvakin, Ph.D.) Date: Thu, 4 Nov 2004 17:54:35 -0500 (EST) Subject: [Bro] bro 09a7 compile problem In-Reply-To: References: Message-ID: All, Anybody saw this? Any ideas? bro-0.9a7$ make cd . && /bin/sh /home/anton/bro-0.9a7/missing --run autoheader configure.in:367: warning: AC_TRY_RUN called without default to allow cross compiling /usr/bin/autoheader: Symbol `RETSIGVAL' is not covered by /usr/share/autoconf/acconfig.h /usr/bin/autoheader: Symbol `ns_msg' is not covered by /usr/share/autoconf/acconfig.h make: *** [stamp-h.in] Error 1 anton$ cat /etc/redhat-release Red Hat Linux release 7.3 (Valhalla) anton$ uname -a Linux bastion 2.4.18-3 #1 Thu Apr 18 07:37:53 EDT 2002 i686 unknown Best, -- Anton Chuvakin, Ph.D., GCIA, GCIH Author of "Security Warrior" from O'Reilly - http://www.securitywarrior.com Security Strategist Product Management Group netForensics - http://www.netForensics.com ************************************************************************************************** The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. ** netForensics has scanned this email for viruses, vandals and malicious content. ** ************************************************************************************************** From christian at whoop.org Fri Nov 5 05:03:46 2004 From: christian at whoop.org (Christian Kreibich) Date: Fri, 05 Nov 2004 13:03:46 +0000 Subject: [Bro] bro 09a7 compile problem In-Reply-To: References: Message-ID: <1099659826.12879.311.camel@ghouls.cl.cam.ac.uk> Hey Anton, nope sorry -- I'll try to find a RH 7.3 machine around to try to reproduce this. Thanks for pointing out. Can you post the version number of your autoconf? Cheers, Christian. On Thu, 2004-11-04 at 22:54, Anton Chuvakin, Ph.D. wrote: > All, > > Anybody saw this? Any ideas? > > bro-0.9a7$ make > cd . && /bin/sh /home/anton/bro-0.9a7/missing --run autoheader > configure.in:367: warning: AC_TRY_RUN called without default to allow > cross compiling > /usr/bin/autoheader: Symbol `RETSIGVAL' is not covered by > /usr/share/autoconf/acconfig.h > /usr/bin/autoheader: Symbol `ns_msg' is not covered by > /usr/share/autoconf/acconfig.h > make: *** [stamp-h.in] Error 1 > > anton$ cat /etc/redhat-release > Red Hat Linux release 7.3 (Valhalla) > > anton$ uname -a > Linux bastion 2.4.18-3 #1 Thu Apr 18 07:37:53 EDT 2002 i686 unknown > > Best, -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From jomcn at mail.com Fri Nov 5 06:11:28 2004 From: jomcn at mail.com (john mcnicholas) Date: Fri, 5 Nov 2004 09:11:28 -0500 Subject: [Bro] possible bug Message-ID: <95BFEDD8-2F34-11D9-BF53-000393C2FCCE@mail.com> Hi, I believe I came across a minor bug in the 0.94 and 0.97 bro code. I'm still new to this project, so it is possible the problem is a user error. In short, when TCP_Connection::SetContentsFile is called with the CONTENTS_BOTH value as the direction, the BroFile object reference counter needs to be incremented else one will encounter an internal reference count error. (or something similar, I don't recall the exact message). In the 0.94 build the program would immediately exit. Notes: - below is a temporary work around that i added. I'm not that familiar with the bro code so I imagine there are other solutions and I'm not recommending one over another. - here is an outline/fragment of a bro script to generate the error. event connection_established( c: connection ) { # 1. see if appropriate protocol/port is being used local filename: string; local f : file; # 2. NOTE: construct appropriate filename here f = open(filename); set_contents_file(c$id,CONTENTS_BOTH,f); } Please let me know if you'd like additional information. John / /----------------------------------------------------------------------- --------------------- void TCP_Connection::SetContentsFile(unsigned int direction, BroFile* f) { if ( direction == CONTENTS_NONE ) { orig->SetContentsFile(0); resp->SetContentsFile(0); } else { if ( direction == CONTENTS_ORIG || direction == CONTENTS_BOTH ) orig->SetContentsFile(f); if ( direction == CONTENTS_RESP || direction == CONTENTS_BOTH ) resp->SetContentsFile(f); } // // this is a wor if (direction==CONTENTS_BOTH) { // JGM: workaround increment the reference count for // the file object // Ref((BroObj *)f); Ref(f); // need to include "File.h" } } From anton at netForensics.com Fri Nov 5 06:21:11 2004 From: anton at netForensics.com (Anton Chuvakin, Ph.D.) Date: Fri, 5 Nov 2004 09:21:11 -0500 (EST) Subject: [Bro] bro 09a7 compile problem In-Reply-To: <1099659826.12879.311.camel@ghouls.cl.cam.ac.uk> References: <1099659826.12879.311.camel@ghouls.cl.cam.ac.uk> Message-ID: > reproduce this. Thanks for pointing out. Can you post the version number > of your autoconf? autoconf-2.13-17 Best, -- Anton Chuvakin, Ph.D., GCIA, GCIH Author of "Security Warrior" from O'Reilly - http://www.securitywarrior.com Security Strategist Product Management Group netForensics - http://www.netForensics.com ************************************************************************************************** The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. ** netForensics has scanned this email for viruses, vandals and malicious content. ** ************************************************************************************************** From JRLee at lbl.gov Fri Nov 5 09:16:20 2004 From: JRLee at lbl.gov (Jason R. Lee) Date: Fri, 05 Nov 2004 09:16:20 -0800 Subject: [Bro] bro 09a7 compile problem In-Reply-To: References: <1099659826.12879.311.camel@ghouls.cl.cam.ac.uk> Message-ID: <418BB564.1030008@lbl.gov> Anoton, Would it be possible for you to upgrade your autotools suite? ( 2.13 came out in Jan of 1999, which makes it almost 6 years old!) The minimal requirements that I have been using with bro are autoconf 2.53 (which came out in 2002) and automake 1.5 (2001) and I know that bro will work with autoconf 2.59 and automake 1.8.5 (both about a year old). Cheers, jason Anton Chuvakin, Ph.D. wrote: >> reproduce this. Thanks for pointing out. Can you post the version number >> of your autoconf? > > > autoconf-2.13-17 > > Best, > -- > Anton Chuvakin, Ph.D., GCIA, GCIH > Author of "Security Warrior" from O'Reilly - > http://www.securitywarrior.com > Security Strategist > Product Management Group > netForensics - http://www.netForensics.com > ************************************************************************************************** > > The contents of this email and any attachments are confidential. > They are intended for the named recipient(s) only. > If you have received this email in error please notify the system > manager or the sender immediately and do not disclose the contents to > anyone or make copies. > > ** netForensics has scanned this email for viruses, vandals and > malicious content. ** > ************************************************************************************************** > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From anton at netForensics.com Fri Nov 5 09:26:00 2004 From: anton at netForensics.com (Anton Chuvakin, Ph.D.) Date: Fri, 5 Nov 2004 12:26:00 -0500 (EST) Subject: [Bro] bro 09a7 compile problem In-Reply-To: <418BB564.1030008@lbl.gov> References: <1099659826.12879.311.camel@ghouls.cl.cam.ac.uk> <418BB564.1030008@lbl.gov> Message-ID: > came out in Jan of 1999, which makes it almost 6 years old!) The minimal > requirements that I have been using with bro are autoconf 2.53 (which came I just linked autoconf to point to 2.53 version and get the same error... > out in 2002) and automake 1.5 (2001) and I know that bro will work with > autoconf 2.59 and automake 1.8.5 (both about a year old). > > Cheers, > jason > > > Anton Chuvakin, Ph.D. wrote: > >>> reproduce this. Thanks for pointing out. Can you post the version number >>> of your autoconf? >> >> >> autoconf-2.13-17 >> >> Best, >> -- >> Anton Chuvakin, Ph.D., GCIA, GCIH >> Author of "Security Warrior" from O'Reilly - http://www.securitywarrior.com >> Security Strategist >> Product Management Group >> netForensics - http://www.netForensics.com >> ************************************************************************************************** >> The contents of this email and any attachments are confidential. >> They are intended for the named recipient(s) only. >> If you have received this email in error please notify the system manager >> or the sender immediately and do not disclose the contents to anyone or >> make copies. >> >> ** netForensics has scanned this email for viruses, vandals and malicious >> content. ** >> ************************************************************************************************** >> _______________________________________________ >> Bro mailing list >> bro at bro-ids.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > -- Anton Chuvakin, Ph.D., GCIA, GCIH Security Strategist Product Management Group netForensics - http://www.netForensics.com 732-393-6071 ************************************************************************************************** The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies. ** netForensics has scanned this email for viruses, vandals and malicious content. ** ************************************************************************************************** From bpatters at fit.edu Sun Nov 7 18:23:34 2004 From: bpatters at fit.edu (Bryan) Date: Sun, 7 Nov 2004 21:23:34 -0500 Subject: [Bro] Using snort signatures in Bro Message-ID: <000601c4c539$f5cae8a0$0501a8c0@Onthedesk> Hello all, I need to compare how bro and snort handle attacks in traffic captures. I have my snort "sig" files, but I don't know the proper syntax of the command line statement. I used snort2bro to read my snort.conf file and the result was a file with a number of bro signatures that I called snort.sig: signature sid-xxx { : : } Can anyone help? I am using bro 0.8. I need to call the .sig file and read my tcpdump capture file at the same time. Thanks, Bryan Florida Tech From sommer at in.tum.de Sun Nov 7 23:42:05 2004 From: sommer at in.tum.de (Robin Sommer) Date: Mon, 8 Nov 2004 08:42:05 +0100 Subject: [Bro] Using snort signatures in Bro In-Reply-To: <000601c4c539$f5cae8a0$0501a8c0@Onthedesk> References: <000601c4c539$f5cae8a0$0501a8c0@Onthedesk> Message-ID: <20041108074205.GA16504@net.informatik.tu-muenchen.de> On Sun, Nov 07, 2004 at 21:23 -0500, Bryan wrote: > Can anyone help? I am using bro 0.8. I need to call the .sig file and > read my tcpdump capture file at the same time. Try something like this (assuming snort.sig being in your current directory): bro -r trace -s ./snort.sig site snort signatures (Don't forget to adapt site.bro to your local environment). Robin -- Robin Sommer * Room 01.08.055 * www.net.in.tum.de TU Muenchen * Phone (089) 289-18006 * sommer at in.tum.de From speisert at alumni.ucsd.edu Tue Nov 9 13:42:22 2004 From: speisert at alumni.ucsd.edu (Sean Peisert) Date: Tue, 9 Nov 2004 13:42:22 -0800 Subject: [Bro] Modifying Bro for NetBSD Message-ID: FYI, the changes in the attached diff were necessary to get Bro 0.9a4a to compile on a NetBSD 2.0_RC4 (x86) installation. Sean -- Sean Peisert (858) 822-3685 (voice) peisert at sdsc.edu (858) 822-5443 (fax) http://www.sdsc.edu/~peisert/ Fellow, San Diego Supercomputer Center University of California, San Diego 9500 Gilman Drive, MC 0505 La Jolla, CA 92093-0505 -------------- next part -------------- A non-text attachment was scrubbed... Name: bro-pub-0.9a4a.diff Type: application/octet-stream Size: 794 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20041109/d9746436/attachment.obj From vern at icir.org Tue Nov 9 15:41:29 2004 From: vern at icir.org (Vern Paxson) Date: Tue, 09 Nov 2004 15:41:29 -0800 Subject: [Bro] not detect {big} scan with scan analyser In-Reply-To: Your message of Thu, 04 Nov 2004 01:56:39 +0100. Message-ID: <200411092341.iA9NfTA2083473@jaguar.icir.org> > not detect any {BIG} scan .... We will need a trace exhibiting the problem, as scan detection is working fine for us. Vern From vern at icir.org Tue Nov 9 15:44:41 2004 From: vern at icir.org (Vern Paxson) Date: Tue, 09 Nov 2004 15:44:41 -0800 Subject: [Bro] Memory pb on 09a7 ? In-Reply-To: Your message of Fri, 05 Nov 2004 01:09:14 +0100. Message-ID: <200411092344.iA9NifA2083666@jaguar.icir.org> > 1099602683.735772 Global_sizes total: 138583K > > Possible help me ? What exactly is the problem you're referring to? Bro can certainly use up 100s of MBs if it's monitoring a busy (1000s pps) link, or if you run it for a long period of time without engaging its various state timeout mechanisms. Vern From vern at icir.org Tue Nov 9 18:24:34 2004 From: vern at icir.org (Vern Paxson) Date: Tue, 09 Nov 2004 18:24:34 -0800 Subject: [Bro] Modifying Bro for NetBSD In-Reply-To: Your message of Tue, 09 Nov 2004 13:42:22 PST. Message-ID: <200411100224.iAA2OYA2088625@jaguar.icir.org> > FYI, the changes in the attached diff were necessary to get Bro > 0.9a4a to compile on a NetBSD 2.0_RC4 (x86) installation. Any chance you can contribute that in terms of autoconf tests? Otherwise, I don't see how we can integrate it. Vern From chema at cs.berkeley.edu Tue Nov 9 18:54:32 2004 From: chema at cs.berkeley.edu (=?iso-8859-1?q?Jos=E9_Mar=EDa_Gonz=E1lez?=) Date: Tue, 9 Nov 2004 19:54:32 -0700 Subject: [Bro] Modifying Bro for NetBSD In-Reply-To: References: Message-ID: <200411091854.32293.chema@cs.berkeley.edu> Sean, Your patch deals mainly with NetBSD addition of an (extra) error parameter in libpcap's pcap_compile_nopcap(). I submitted a patch to detect this some time ago: http://mailman.icsi.berkeley.edu/pipermail/bro/2003-December/001364.html [BTW, and off-topic, would it be possible to anonymize email addresses in the mailing list?] Unfortunately, I didn't have a NetBSD box to test it, and it seems it may not be working properly. On the other hand, your patch seems to add even a new extra parameter. I checked NetBSD 2.0, and the function API is: [ ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-release-2-0/src/lib/libpcap/gencode.c ] pcap_compile_nopcap(int snaplen_arg, int linktype_arg, struct bpf_program *program, char *buf, int optimize, bpf_u_int32 mask, char *errbuf) I.e., just the error buffer parameter. This seems incoherent with your patch. Can you please send me your pcap.h file? It should be located at /usr/include/pcap.h, or maybe /usr/include/[lib]pcap/pcap.h Last, is there any NetBSD machine I can have access to? -Chema On Tuesday 09 November 2004 13:42, Sean Peisert wrote: > FYI, the changes in the attached diff were necessary to get Bro > 0.9a4a to compile on a NetBSD 2.0_RC4 (x86) installation. > > Sean > diff -r bro-pub-0.9a4a/src/BPF_Program.cc bro-pub-0.9a4a-sean/src/BPF_Program.cc 29c29,30 < #include "pcap-int.h" --- > /*#include "pcap-int.h"*/ > #include "/usr/src/lib/libpcap/pcap-int.h" 63c64 < int optimize, bpf_u_int32 mask) --- > int optimize, bpf_u_int32 mask, char* dummy) 125c126 < (char *) filter, optimize, netmask, error); --- > (char *) filter, optimize, netmask, error, NULL); 130c131 < (char*) filter, optimize, netmask); --- > (char*) filter, optimize, netmask, NULL); diff -r bro-pub-0.9a4a/src/PktSrc.cc bro-pub-0.9a4a-sean/src/PktSrc.cc 31a32,33 > #define DLT_LINUX_SLL 113 > 120c122 < current_dumper = pcap_dump_open(pd, file); --- > current_dumper = pcap_dump_open(pd, (char*)file); Only in bro-pub-0.9a4a-sean/src: libedit From speisert at alumni.ucsd.edu Tue Nov 9 19:16:10 2004 From: speisert at alumni.ucsd.edu (Sean Peisert) Date: Tue, 9 Nov 2004 19:16:10 -0800 Subject: [Bro] Modifying Bro for NetBSD In-Reply-To: <200411091854.32293.chema@cs.berkeley.edu> References: <200411091854.32293.chema@cs.berkeley.edu> Message-ID: Chema, I attached the /usr/include/pcap.h file. Offhand, the arguments appear to be the same as the ones I changed the Bro files to require. Are you sure they're incongruent? Unfortunately, I don't have a NetBSD machine to give you access to right at the moment, but I could probably get one up next week if nobody else on the list can help. It'll even run on your toaster, in case you have time to try. :) Sean At 7:54 PM -0700 11/9/04, Jos? Mar?a Gonz?lez wrote: >Sean, > >Your patch deals mainly with NetBSD addition of an >(extra) error parameter in libpcap's pcap_compile_nopcap(). >I submitted a patch to detect this some time ago: > >http://mailman.icsi.berkeley.edu/pipermail/bro/2003-December/001364.html > >[BTW, and off-topic, would it be possible to anonymize >email addresses in the mailing list?] > >Unfortunately, I didn't have a NetBSD box to test it, >and it seems it may not be working properly. > > >On the other hand, your patch seems to add even a >new extra parameter. I checked NetBSD 2.0, and the >function API is: > >[ >ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-release-2-0/src/lib/libpcap/gencode.c >] > >pcap_compile_nopcap(int snaplen_arg, int linktype_arg, > struct bpf_program *program, > char *buf, int optimize, bpf_u_int32 mask, char *errbuf) > >I.e., just the error buffer parameter. This seems incoherent >with your patch. > >Can you please send me your pcap.h file? It should be >located at /usr/include/pcap.h, or maybe /usr/include/[lib]pcap/pcap.h > >Last, is there any NetBSD machine I can have access to? > >-Chema > > > >On Tuesday 09 November 2004 13:42, Sean Peisert wrote: > > FYI, the changes in the attached diff were necessary to get Bro > > 0.9a4a to compile on a NetBSD 2.0_RC4 (x86) installation. > > > > Sean > > > > > > > >diff -r bro-pub-0.9a4a/src/BPF_Program.cc >bro-pub-0.9a4a-sean/src/BPF_Program.cc >29c29,30 >< #include "pcap-int.h" >--- >> /*#include "pcap-int.h"*/ >> #include "/usr/src/lib/libpcap/pcap-int.h" >63c64 >< int optimize, bpf_u_int32 mask) >--- >> int optimize, bpf_u_int32 mask, char* dummy) >125c126 >< (char *) filter, optimize, netmask, error); >--- >> (char *) filter, optimize, netmask, error, NULL); >130c131 >< (char*) filter, optimize, netmask); >--- >> (char*) filter, optimize, netmask, NULL); >diff -r bro-pub-0.9a4a/src/PktSrc.cc bro-pub-0.9a4a-sean/src/PktSrc.cc >31a32,33 >> #define DLT_LINUX_SLL 113 >> >120c122 >< current_dumper = pcap_dump_open(pd, file); >--- >> current_dumper = pcap_dump_open(pd, (char*)file); >Only in bro-pub-0.9a4a-sean/src: libedit >_______________________________________________ >Bro mailing list >bro at bro-ids.org >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro -- Sean Peisert (858) 822-3685 (voice) peisert at sdsc.edu (858) 822-5443 (fax) http://www.sdsc.edu/~peisert/ Fellow, San Diego Supercomputer Center University of California, San Diego 9500 Gilman Drive, MC 0505 La Jolla, CA 92093-0505 -------------- next part -------------- A non-text attachment was scrubbed... Name: pcap.h Type: application/octet-stream Size: 5168 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20041109/e15a6a64/attachment.obj From vern at icir.org Wed Nov 10 15:23:08 2004 From: vern at icir.org (Vern Paxson) Date: Wed, 10 Nov 2004 15:23:08 -0800 Subject: [Bro] Connection summaries question In-Reply-To: Your message of Thu, 14 Oct 2004 14:33:08 BST. Message-ID: <200411102323.iAANN8A2008263@jaguar.icir.org> [catching up on old mail] > - When Bro encounters a flow mid-stream and that flow gets shut down > normally in the end, I see "SF" in connection summaries. Yes. > - 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. Yep. > 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. You're right that that's the better interpretation. The core problem is that there are a whole lot of different possible connection states - in particular, more than TCP's own state machine allows for, since it assumes correct establishment - and Bro's state-tracking evolved from an initial approach that assumed correct TCP operation. Once I integrate Mark's addition of state-tracking, this problem will basically go away. Vern From jomcn at mail.com Tue Nov 16 10:00:21 2004 From: jomcn at mail.com (john mcnicholas) Date: Tue, 16 Nov 2004 13:00:21 -0500 Subject: [Bro] adding bifs Message-ID: <20041116180015.IXOQ25072.out010.verizon.net@achilles> Hi. Just a couple of questions. 1. What is the proper procedure for having bifs (built-in-functions) added to the core of bro? For a prototype I went ahead and added 2 functions (listed below) and I was wondering if they could be put into the official bro distribution. The changes were very basic but I am more than willing to submit source code changes if someone could direct me to some documentation on the proper procedures, or even who to send the changes to so they can be reviewed and/or approved. // here are the functions a. global get_contents_file: function(cid: conn_id, direction: count): file; b. global get_file_name: function(f: file): string; 2. In short, in the .97 build how do you write to the syslog from a ".bro" policy script? I realize the terminology has changed from the .94 to the .97 baseline for the concepts of "log/alert and notice" and unless I'm mistaken the "log" function has been removed in .97. I'm not sure if the old (.94) "log" function would always, or conditionally write to the system log (syslog), but that is what I'd like to do now. If it isn't possible, what do you suggest I do? For example, should I add another built-in-function? Thanks in advance for your help. john From vern at icir.org Tue Nov 16 20:58:59 2004 From: vern at icir.org (Vern Paxson) Date: Tue, 16 Nov 2004 20:58:59 -0800 Subject: [Bro] adding bifs In-Reply-To: Your message of Tue, 16 Nov 2004 13:00:21 EST. Message-ID: <200411170458.iAH4wxA2093952@jaguar.icir.org> > 1. What is the proper procedure for having bifs (built-in-functions) added > to the core of bro? Send me contextual diffs and a bit of text documenting the functionality. > 2. In short, in the .97 build how do you write to the syslog from a ".bro" > policy script? The "log" statement is now called "alarm". Vern From jomcn at mail.com Mon Nov 29 11:12:02 2004 From: jomcn at mail.com (john mcnicholas) Date: Mon, 29 Nov 2004 14:12:02 -0500 Subject: [Bro] tcp contents Message-ID: <8D366936-423A-11D9-98F3-000393C2FCCE@mail.com> In short, this is what I'm trying to do: I want to selectively save the payload/contents of a TCP stream to a file just based on the protocol/port number. Note: I can currently do this using 2 different approaches but I'm looking for the "right" way. a - (this approach works but I modified the source code) The small TCP_TransactionConnection class below in conjunction with a simple policy script does appear to successfully save the TCP contents for POP3, SMTP and HTTP. (Yes trivial code changes were made to substitute the TCP_TransactionConnection for SMTP_Conn and HTTP_Conn in Sessions.cc ) The simple policy script filters on the desired ports and assigns a contents file each time a tcp connection is created. b. - (this approach also works but it is not as efficient as above) I was able to save the HTTP and SMTP data by just creating empty event handlers for ("event smtp_data" and "event http_reply") in conjunction with the identical policy script used above. This is less efficient than the first approach because of all the processing done by the HTTP_Conn and SMTP_Conn classes which would not be utilized by this prototype/application. c. (this approach may have potential but it doesn't look like it can work in the current code) There is a TCP_ConnectionContents class that gets instantiated if a "new_connection_contents" policy handler exists (in Sessions.cc) but it doesn't look it can limit itself to a certain number of protocols/ports. In addition, it doesn't look like the code there was fully implemented in the BuildEndPoints method for the TCP_ConnectionContents class (the TCP_CONTENTS_BOTH case is missing). Bottom line. Since I'm not that familiar with the source code how does this feature/goal fit into the overall design of bro and is there already a way to accomplish it? Determining if this feature is of value is probably the first question. Thanks again for your help and your time. If anything is unclear please let me know. John / /----------------------------------------------------------------------- ------ //---- here is the TCP_TransaactionConnection code that I've been using for testing. // // // class TCP_TransactionConnection : public TCP_Connection { public: TCP_TransactionConnection(NetSessions* s, HashKey* k, double t, const ConnID* id, const struct tcphdr* tp); void BuildEndpoints(); private: }; TCP_TransactionConnection::TCP_TransactionConnection(NetSessions* s, HashKey* k, double t, const ConnID* id, const struct tcphdr* tp) : TCP_Connection(s, k, t, id, tp) { } void TCP_TransactionConnection::BuildEndpoints() { // ! NUL_sensitive, skip_partial orig->AddContentsProcessor(new TCP_ContentLine(orig, 1, 0, 1)); resp->AddContentsProcessor(new TCP_ContentLine(resp, 0, 0, 1)); // sender = orig; } From vern at icir.org Mon Nov 29 13:37:27 2004 From: vern at icir.org (Vern Paxson) Date: Mon, 29 Nov 2004 13:37:27 -0800 Subject: [Bro] tcp contents In-Reply-To: Your message of Mon, 29 Nov 2004 14:12:02 EST. Message-ID: <200411292137.iATLbRA2051928@jaguar.icir.org> > In short, this is what I'm trying to do: I want to selectively save > the payload/contents of a TCP stream to a file just based on the > protocol/port number. If you want to do this offline processing a trace, then it's very easy - just "bro -f 'tcp port 80 or tcp port 25' -r trace contents", for example. If you want todo it online while also doing other work, then a natural way would be something like: global interesting_services = { smtp, http, }; event connection_established(c: connection) { if ( c$id$resp_p in interesting_services ) demux_conn(c$id, "interesting", "orig", "resp"); } (with the caveat that I haven't tested this) Vern From jomcn at mail.com Mon Nov 29 18:45:54 2004 From: jomcn at mail.com (john mcnicholas) Date: Mon, 29 Nov 2004 21:45:54 -0500 Subject: [Bro] tcp contents In-Reply-To: <200411292137.iATLbRA2051928@jaguar.icir.org> Message-ID: <20041130024552.YADU1396.out009.verizon.net@achilles> > If you want todo it online while also doing other work, then a > natural way would be something like: > > global interesting_services = { smtp, http, }; > > event connection_established(c: connection) > { > if ( c$id$resp_p in interesting_services ) > demux_conn(c$id, "interesting", "orig", "resp"); > } > >(with the caveat that I haven't tested this) Thanks for the tip. Good news: I went ahead and tested it and it worked fine when saving the contents to 2 separate files. Bad news: Although it took just a simple modification to a copy of "demunx_conn()", I couldn't get it to work when writing to 1 file by using the CONTENTS_BOTH flag. Assuming the above observations are true, then unless someone can state why CONTENTS_BOTH has problems I will go ahead and continue investigating tomorrow. More details on the "bad news": - at a minimum the data is not ordered properly. this is readily apparent when examining the POP3 protocol when there isn't any mail to deliver. perhaps it is as simple as the data being cached and then flushed? (I'm now suspicious of this, and will look at it tomorrow. sorry for the premature post.) - for HTTP it also appeared the data was not properly ordered. i can't say for certain but it appeared that the first "get" was frequently missing while the response was properly added. - two workarounds for the above were to either a: have the HTTP_Conn or SMTP_Conn classes constructed by inserting the empty "events" for those analyzers (correct term?) b: instantiating the TCP_TransactionContents class for HTTP, SMTP, and POP3. The simple class seems to flush the data properly. Perhaps I'm swimming upstream by trying to use the single file approach, but it really does seem doable. Thanks for the help. John From rmkml at wanadoo.fr Mon Nov 29 22:48:30 2004 From: rmkml at wanadoo.fr (rmkml) Date: Tue, 30 Nov 2004 07:48:30 +0100 (CET) Subject: [Bro] Check tcp sequence number ? Message-ID: Hi, Bro 09a7 check/verify tcp sequence number ? (fbsd410 platform) Regards Rmkml at Wanadoo.fr From vern at icir.org Tue Nov 30 01:20:34 2004 From: vern at icir.org (Vern Paxson) Date: Tue, 30 Nov 2004 01:20:34 -0800 Subject: [Bro] tcp contents In-Reply-To: Your message of Mon, 29 Nov 2004 21:45:54 EST. Message-ID: <200411300920.iAU9KYA2001102@jaguar.icir.org> > Bad news: Although it took just a simple modification to a copy of > "demunx_conn()", I couldn't get it to work when writing to 1 file by using > the CONTENTS_BOTH flag. Ah - I realized the key problem, which is that CONTENTS_BOTH is not in fact a valid parameter for set_contents_file. The way that contents are extracted from streams, it simply can't work. (The definition is lying around because it's used internal to the event engine in a slightly different context.) Is there some reason why you want to have both directions in a single file? If so, then the way to do it is by defining a tcp_contents handler that writes out the contents directly to a file: event tcp_contents(c: connection, is_orig: bool, seq: count, contents: string) though this won't easily do the right thing in the presence of packet loss/retransmission. Vern From jomcn at mail.com Tue Nov 30 04:21:05 2004 From: jomcn at mail.com (john mcnicholas) Date: Tue, 30 Nov 2004 07:21:05 -0500 Subject: [Bro] tcp contents In-Reply-To: <200411300920.iAU9KYA2001102@jaguar.icir.org> Message-ID: <20041130122105.RVMG4719.out006.verizon.net@achilles> > Is there some reason why you want to have both directions in a single file? The initial reason was twofold: just to reduce the number of files and to be compatible with a prototype that had been developed. Clearly neither are critical and if the 2 file approach is faster/efficient then that should be enough to trump the single file approach given the importance of speed. > Ah - I realized the key problem, which is that CONTENTS_BOTH is not in > fact a valid parameter for set_contents_file. The way that contents are > extracted from streams, it simply can't work. (The definition is lying > around because it's used internal to the event engine in a slightly > different context.) I really don't want anyone spending more time on this but: a. do you think I just didn't look hard enough at the data for a single file (i.e., it wasn't working when I thought it was) or b. the single file approach would work "most of the time" or all of the time if a connection (such as HTTP_Conn or SMTP_Conn) added a contents processor derived from TCP_ContentLine. i.e. it would work if the TCP_Connection's BuildEndpoints() method did something functionally equivalent to: orig->AddContentsProcessor( new TCP_ContentLine(orig,1,0,1)); resp->AddContentsProcessor( new TCP_ContentLine(resp,0,0,1)); Obviously "most of the time" isn't good enough but it would explain why a cursory check of the output looked valid. Once again even if the single file did work, if the 2 file approach has a measurable speed advantage we'll probably make the necessary changes to our protocol handlers/applications. Thanks again for your time and help. John From rpang at CS.Princeton.EDU Tue Nov 30 07:14:06 2004 From: rpang at CS.Princeton.EDU (Ruoming Pang) Date: Tue, 30 Nov 2004 10:14:06 -0500 Subject: [Bro] tcp contents In-Reply-To: <200411300920.iAU9KYA2001102@jaguar.icir.org> References: <200411300920.iAU9KYA2001102@jaguar.icir.org> Message-ID: <7A8607CB-42E2-11D9-B5ED-000D9335A7D8@cs.princeton.edu> > event tcp_contents(c: connection, is_orig: bool, seq: count, contents: > string) > > though this won't easily do the right thing in the presence of packet > loss/retransmission. In fact, tcp_contents won't be affected by packet loss/retransmission, and it always delivers contents in the order of TCP sequence numbers, because it is called after TCP reassembly in TCP_Contents::DeliverBlock(). However: 1) There can be content gaps in case some packets are not captured by Bro. Gaps are reported by event content_gap, but you can also tell by looking at parameter and length of of tcp_contents. 2) Also, if the connection is "skipped" (some analyzers, e.g. Netbios/SSN, will automatically skip after seeing a content gap.) function skip_further_processing%(cid: conn_id%): bool the content afterwards won't reach tcp_contents. The same also applies to "TCP content files". Ruoming From christian at whoop.org Tue Nov 30 08:56:36 2004 From: christian at whoop.org (Christian Kreibich) Date: Tue, 30 Nov 2004 16:56:36 +0000 Subject: [Bro] Check tcp sequence number ? In-Reply-To: References: Message-ID: <1101833796.28108.132.camel@localhost> On Tue, 2004-11-30 at 06:48, rmkml wrote: > Hi, > > Bro 09a7 check/verify tcp sequence number ? Yep sure -- you cannot do flow reassembly (which is necessary for any analysis beyond the packet level) without looking closely at the TCP sequence numbers. Cheers, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org From vern at icir.org Tue Nov 30 09:12:25 2004 From: vern at icir.org (Vern Paxson) Date: Tue, 30 Nov 2004 09:12:25 -0800 Subject: [Bro] tcp contents In-Reply-To: Your message of Tue, 30 Nov 2004 07:21:05 EST. Message-ID: <200411301712.iAUHCPA2095464@jaguar.icir.org> > a. do you think I just didn't look hard enough at the data for a single file > (i.e., it wasn't working when I thought it was) > or > b. the single file approach would work "most of the time" or all of the time > if a connection (such as HTTP_Conn or SMTP_Conn) added a contents processor > derived from TCP_ContentLine. i.e. it would work if the TCP_Connection's > BuildEndpoints() method did something functionally equivalent to: Closer to b. In particular, the internal mechanism uses seek() to find the right position in the file, so two streams writing concurrently to the same file will overwrite one anothe in unpredictable ways. > Obviously "most of the time" isn't good enough but it would explain why a > cursory check of the output looked valid. Yes, that could well be the case. Vern From vern at icir.org Tue Nov 30 09:12:59 2004 From: vern at icir.org (Vern Paxson) Date: Tue, 30 Nov 2004 09:12:59 -0800 Subject: [Bro] tcp contents In-Reply-To: Your message of Tue, 30 Nov 2004 10:14:06 EST. Message-ID: <200411301712.iAUHCxA2095486@jaguar.icir.org> > In fact, tcp_contents won't be affected by packet loss/retransmission, > and it always delivers contents in the order of TCP sequence numbers, > because it is called after TCP reassembly in > TCP_Contents::DeliverBlock(). Ah!, yes, you're right - thanks for the correction. Vern From rmkml at wanadoo.fr Tue Nov 30 13:00:11 2004 From: rmkml at wanadoo.fr (rmkml) Date: Tue, 30 Nov 2004 22:00:11 +0100 (CET) Subject: [Bro] Check tcp sequence number ? In-Reply-To: <1101833796.28108.132.camel@localhost> References: <1101833796.28108.132.camel@localhost> Message-ID: yes, but explain my pb : $ telnet xxx $ hping2 send Push on tcp open telnet to xxx my xxx Ack, but Push sequence number is bad bro (snort/prelude/firestorm) not event this ... Strange ? Regards Rmkml at Wanadoo.fr On Tue, 30 Nov 2004, Christian Kreibich wrote: > Date: Tue, 30 Nov 2004 16:56:36 +0000 > From: Christian Kreibich > To: Bro List > Subject: Re: [Bro] Check tcp sequence number ? > > On Tue, 2004-11-30 at 06:48, rmkml wrote: >> Hi, >> >> Bro 09a7 check/verify tcp sequence number ? > > Yep sure -- you cannot do flow reassembly (which is necessary for any > analysis beyond the packet level) without looking closely at the TCP > sequence numbers. > > Cheers, > Christian. > -- > ________________________________________________________________________ > http://www.cl.cam.ac.uk/~cpk25 > http://www.whoop.org > > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > > From christian at whoop.org Tue Nov 30 17:44:12 2004 From: christian at whoop.org (Christian Kreibich) Date: Wed, 01 Dec 2004 01:44:12 +0000 Subject: [Bro] Check tcp sequence number ? In-Reply-To: References: <1101833796.28108.132.camel@localhost> Message-ID: <1101865451.28110.192.camel@localhost> On Tue, 2004-11-30 at 21:00, rmkml wrote: > yes, > but explain my pb : > $ telnet xxx > $ hping2 send Push on tcp open telnet to xxx > my xxx Ack, but Push sequence number is bad You mean intentionally bad (i.e., you set it to some garbage value), I presume. > bro (snort/prelude/firestorm) not event this ... > Strange ? No -- there are precise semantics in TCP regarding what sequence numbers are acceptable at a given time, so anything outside of the acceptable window is just ignored. There's no danger of confusion here between the IDS and the end host, so it's not worth reporting. Note that Bro *does* report content gaps though. Regards, Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org