From vallentin at icir.org Mon Nov 1 14:13:36 2010 From: vallentin at icir.org (Matthias Vallentin) Date: Mon, 1 Nov 2010 14:13:36 -0700 Subject: [Bro] set initializers (Re: Bro scripts) In-Reply-To: <20101030205200.CE9D736A4F2@taffy.ICSI.Berkeley.EDU> References: <20101029065615.GK16825@icsi.berkeley.edu> <20101030205200.CE9D736A4F2@taffy.ICSI.Berkeley.EDU> Message-ID: <20101101211336.GE16825@icsi.berkeley.edu> > .... $cookies=set("xs", "c_user", "sid") That works, thanks. I attached a revamped version of the sidejacking detector which should exhibit less false positives now (and has slightly improved logging). Matthias -------------- next part -------------- # A simple sidejacking detector. # # The script raises an alarm whenever more than one client makes use of the # same cookie, where a user is defined a as (IP, user agent) pair. @load notice @load http-request @load http-reply module HTTP; export { redef enum Notice += { Sidejacking }; const cookie_expiration = 1 hr &redef; type cookie_info: record { url: pattern; # URL pattern matched against Host header. keys: set[string] &optional; # Cookie keys that define the user session. pat: pattern &optional; # Cookie keys pattern, instead of a set. }; # List of cookie information per service (taken from Firesheep handlers). const cookie_list: table[string] of cookie_info = { ["Amazon"] = [$url=/amazon.com/, $keys=set("x-main")], ["Basecamp"] = [$url=/basecamphq.com/, $keys=set("_basecamp_session", "session_token")], ["bit.ly"] = [$url=/bit.ly/, $keys=set("user")], ["Cisco"] = [$url=/cisco.com/, $keys=set("SMIDENTITY")], ["CNET"] = [$url=/cnet.com/, $keys=set("urs_sessionId")], ["Dropbox"] = [$url=/dropbox.com/, $keys=set("lid")], ["Enom"] = [$url=/enom.com/, $keys=set("OatmealCookie", "EmailAddress")], ["Evernote"] = [$url=/evernote.com/, $keys=set("auth")], ["Facebook"] = [$url=/facebook.com/, $keys=set("xs", "c_user", "sid")], ["Flickr"] = [$url=/flickr.com/, $keys=set("cookie_session")], ["Foursquare"] = [$url=/foursquare.com/, $keys=set("ext_id", "XSESSIONID")], ["GitHub"] = [$url=/github.com/, $keys=set("_github_ses")], ["Google"] = [$url=/google.com/, $keys=set("NID", "SID", "HSID", "PREF")], ["Gowalla"] = [$url=/gowalla.com/, $keys=set("__utma")], ["Hacker News"] = [$url=/news.ycombinator.com/, $keys=set("user")], ["Harvest"] = [$url=/harvestapp.com/, $keys=set("_enc_sess")], ["NY Times"] = [$url=/nytimes.com/, $keys=set("NYT-s", "nyt-d")], ["Pivotal Tracker"] = [$url=/pivotaltracker.com/, $keys=set("_myapp_session")], ["Slicehost"] = [$url=/manage.slicehost.com/, $keys=set("_coach_session_id")], ["tumblr"] = [$url=/tumblr.com/, $keys=set("pfp")], ["Twitter"] = [$url=/twitter.com/, $keys=set("_twitter_sess", "auth_token")], ["Yahoo"] = [$url=/yahoo.com/, $keys=set("T", "Y")], ["Yelp"] = [$url=/yelp.com/, $keys=set("__utma")], ["Windows Live"] = [$url=/live.com/, $keys=set("MSPProf", "MSPAuth", "RPSTAuth", "NAP")], ["Wordpress"] = [$url=/wordpress.com/, $pat=/wordpress_[0-9a-fA-F]+/] } &redef; } # Map cookies to users, who are defined as a (address, user-agent) pair. type cookie_map: table[string] of set[addr,string] ; global evict_reported: function(map: cookie_map, cookie: string) : interval; global cookies: cookie_map &write_expire = cookie_expiration &expire_func=evict_reported; # Hijacked sessions that have already been reported. global hijacking_reported: set[string]; # Once a cookie entry expires, this function evicts the corresponding entry # from the set of reported cookies. function evict_reported(map: cookie_map, cookie: string) : interval { delete hijacking_reported[cookie]; return 0 secs; } # Create a unique user session identifier based on a pattern of cookie keys. function sessionize(cookie: string, info: cookie_info) : string { local id = ""; local fields = split(cookie, /; /); if (info?$pat) { for (i in fields) { local s = split1(fields[i], /=/); if (s[1] == info$pat) id += s[2]; } } if (info?$keys) { local matches: set[string]; matches = set(); for (i in fields) { s = split1(fields[i], /=/); if (s[1] in info$keys) add matches[s[2]]; } if (|matches| == |info$keys|) for (m in matches) id += m; } return id; } event http_all_headers(c: connection, is_orig: bool, hlist: mime_header_list) { if (! is_orig) return; local cookie = ""; local ua = ""; local host = ""; for (i in hlist) { local hdr = hlist[i]$name; local value = hlist[i]$value; if (hdr == "COOKIE") cookie = value; else if (hdr == "USER-AGENT") ua = value; else if (hdr == "HOST") host = to_lower(value); } if (cookie == "") return; local id = ""; local desc = ""; if (host != "") for (k in cookie_list) { local info = cookie_list[k]; if (info$url in host) { id = sessionize(cookie, info); desc = k; break; } } if (id == "") id = cookie; if (id !in cookies) cookies[id] = set() &mergeable; local client = c$id$orig_h; add cookies[id][client, ua]; if (|cookies[id]| <= 1) return; if (id !in hijacking_reported) { local s = lookup_http_request_stream(c); desc = (desc == "" ? "" : fmt("%s ", desc)); NOTICE([$note=Sidejacking, $src=client, $msg=fmt("%ssession hijacked by %s (%d users/cookie)", desc, client, |cookies[id]|)]); add hijacking_reported[id]; } } From ish at unx.ca Tue Nov 2 16:02:43 2010 From: ish at unx.ca (Jason Ish) Date: Tue, 2 Nov 2010 17:02:43 -0600 Subject: [Bro] Endace support in use? In-Reply-To: <20101018193306.GA71746@icir.org> References: <20101018193306.GA71746@icir.org> Message-ID: On Mon, Oct 18, 2010 at 1:33 PM, Robin Sommer wrote: > Bro currently comes with native support for Endace cards (i.e., > using the Endace API directly, not via their libpcap-compatible > interface). > > The support is enabled by configuring with --with-dag. As we're > cleaning up the Bro distribution, we were wondering if anybody is > using this functionality and would object seeing it removed? Hi Robin, I'm posting this on behalf of the Endace CEO, Stuart Wilson as he is not a member of this list and is unable to post. Note that I also work for Endace, but am subscribed here with my personal address: Hi Robin. We?re seeing need from the Government space to retain this, and of course we?d like to see it retained as well. We?re happy to put some work to maintain it if you can leave it in please. Updating to the latest drivers etc. might be useful. Thanks, Stuart Wilson From mcholste at gmail.com Tue Nov 2 16:56:40 2010 From: mcholste at gmail.com (Martin Holste) Date: Tue, 2 Nov 2010 18:56:40 -0500 Subject: [Bro] Endace support in use? In-Reply-To: References: <20101018193306.GA71746@icir.org> Message-ID: We have an Endace card and I would like to give Bro a shot on it at some point in the future. On Tue, Nov 2, 2010 at 6:02 PM, Jason Ish wrote: > On Mon, Oct 18, 2010 at 1:33 PM, Robin Sommer wrote: >> Bro currently comes with native support for Endace cards (i.e., >> using the Endace API directly, not via their libpcap-compatible >> interface). >> >> The support is enabled by configuring with --with-dag. As we're >> cleaning up the Bro distribution, we were wondering if anybody is >> using this functionality and would object seeing it removed? > > Hi Robin, > > I'm posting this on behalf of the Endace CEO, Stuart Wilson as he is > not a member of this list and is unable to post. ?Note that I also > work for Endace, but am subscribed here with my personal address: > > Hi Robin. > > We?re seeing need from the Government space to retain this, and of > course we?d like to see it retained as well. > > We?re happy to put some work to maintain it if you can leave it in > please. ?Updating to the latest drivers etc. might be useful. > > Thanks, > Stuart Wilson > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > From mcholste at gmail.com Tue Nov 2 20:54:06 2010 From: mcholste at gmail.com (Martin Holste) Date: Tue, 2 Nov 2010 22:54:06 -0500 Subject: [Bro] time machine filesize issue In-Reply-To: <20101030205203.A6FAC36A4F2@taffy.ICSI.Berkeley.EDU> References: <20101030205203.A6FAC36A4F2@taffy.ICSI.Berkeley.EDU> Message-ID: Further testing shows that filesize > 2000m (including 2g for some reason) leads to tm not rolling the file ever. On Sat, Oct 30, 2010 at 3:52 PM, Vern Paxson wrote: >> With filesize set at exactly 280g (279g does not produce the problem) >> tm will create one disk fifo file per packet in the workdir for each >> evicted packet with a disk setting of 1000g. ?I am only using one >> default class for "all." > > That sounds like something is wrapping and going negative at the 2^38 barrier. > > ? ? ? ? ? ? ? ?Vern > From seth at icir.org Wed Nov 3 08:41:53 2010 From: seth at icir.org (Seth Hall) Date: Wed, 3 Nov 2010 11:41:53 -0400 Subject: [Bro] Endace support in use? In-Reply-To: References: <20101018193306.GA71746@icir.org> Message-ID: <1A982168-8770-483B-928A-8FBE69D82F72@icir.org> On Nov 2, 2010, at 7:02 PM, Jason Ish wrote: > We?re happy to put some work to maintain it if you can leave it in > please. Updating to the latest drivers etc. might be useful. Excuse my ignorance, but what benefits are gained from using the native API as opposed to using the customized libpcap? .Seth From robin at icir.org Wed Nov 3 08:46:21 2010 From: robin at icir.org (Robin Sommer) Date: Wed, 3 Nov 2010 08:46:21 -0700 Subject: [Bro] Endace support in use? In-Reply-To: References: <20101018193306.GA71746@icir.org> Message-ID: <20101103154621.GA65232@icir.org> On Tue, Nov 02, 2010 at 17:02 -0600, Jason Ish wrote: > We?re seeing need from the Government space to retain this, and of > course we?d like to see it retained as well. Hmm ... As I had not heard from anybody in reply to my original mail, we have actually already moved ahead and removed the code from the current development version. We are in the process of restructuring Bro's packaging and installation setup, and while doing so, we are removing a number of things that don't appear to be in serious use anywhere, primarily to reduce the future maintainace burden. Do you have an idea how many sites will be affected by not having the Endace API support in Bro? What is actually the advantage of using the native API over the libpcap wrapper (which is what everbody I heard from is currently doing already)? > We?re happy to put some work to maintain it if you can leave it in > please. Thanks for the offer. I think what we could do is postpone this for now until we get closer to the next release and then revisit the question and potentially add the support back in if that would be really helpful for some sites. Doing so should generally be pretty straight-forward but we'd indeed need some help with that to make sure it's working as expected as we don't have any of the cards available ourselves. Does that sound ok for now? Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From bboe at cs.ucsb.edu Wed Nov 3 13:49:02 2010 From: bboe at cs.ucsb.edu (Bryce Boe) Date: Wed, 3 Nov 2010 13:49:02 -0700 Subject: [Bro] TCP Flow Packet Counts Message-ID: Hi, I'm trying to write a simple bro policy script that uses the default TCP policy output format, with the addition of packet counts per flow in each direction. For that I'm actually modifying the analy.bro script, however I've noticed that with my sample trace, the originator packet count is almost always zero. How can I get the endpoint_status to accurately reflect the number of packets sent in both directions for the flow? Also am I safe to assume that the number of bytes sent in each direction are correct in the endpoint structure? I tried to trace this problem down a bit and determined that when Analyzer::DeliverPacket calls the class's DeliverPacket method, only a fraction of the time does it go to TCPStats_Analyzer::DeliverPacket method whereas the remainder of the time the TCP_Analyzer::DeliverPacket method is called. Thus this leads me to believe that many of the packets don't have the correct Analyzer class (TCPStats_Analyzer) associated with it, however I am not sure how to fix this problem. Any help would be greatly appreciated. Thanks, Bryce Boe From vern at icir.org Thu Nov 4 10:54:40 2010 From: vern at icir.org (Vern Paxson) Date: Thu, 04 Nov 2010 10:54:40 -0700 Subject: [Bro] TCP Flow Packet Counts In-Reply-To: (Wed, 03 Nov 2010 13:49:02 PDT). Message-ID: <20101104175440.6432436A4EC@taffy.ICSI.Berkeley.EDU> > however I've noticed that with my sample trace, the originator > packet count is almost always zero Can you send along the script you're using and a trace snippet that demonstrates the problem? (Also, what version of Bro are you running?) I tried on a short trace just now and I get packet counts in both directions. Could you be using a capture filter that doesn't capture data packets from the originator? Vern From gregor at icir.org Thu Nov 4 14:06:20 2010 From: gregor at icir.org (Gregor Maier) Date: Thu, 04 Nov 2010 14:06:20 -0700 Subject: [Bro] TCP Flow Packet Counts In-Reply-To: References: Message-ID: <4CD3204C.6000107@icir.org> Hi, The current version of the analy Analyzer isn't working for this. Only packets containing TCP payload are passed to the stats analyzer. I have a branch that, among other things, also correctly tracks packets and bytes on the wire (Bro's conn.log sizes are based on sequence numbers). I can sent you a pointer to the branch if you want to. Note, however, that my branch tracks a bunch of other things per connection (including window size, handshake TTL, TCP options, etc., so it need more state per connection. OTOH, I was planning on integrating just the size counter into Bro anyway. If you are interested in that, I can move that topic up on my priority list.... cu Gregor On 11/3/10 13:49 , Bryce Boe wrote: > Hi, > > I'm trying to write a simple bro policy script that uses the default > TCP policy output format, with the addition of packet counts per flow > in each direction. For that I'm actually modifying the analy.bro > script, however I've noticed that with my sample trace, the originator > packet count is almost always zero. How can I get the endpoint_status > to accurately reflect the number of packets sent in both directions > for the flow? Also am I safe to assume that the number of bytes sent > in each direction are correct in the endpoint structure? > I tried to trace this problem down a bit and determined that when > Analyzer::DeliverPacket calls the class's DeliverPacket method, only a > fraction of the time does it go to TCPStats_Analyzer::DeliverPacket > method whereas the remainder of the time the > TCP_Analyzer::DeliverPacket method is called. Thus this leads me to > believe that many of the packets don't have the correct Analyzer class > (TCPStats_Analyzer) associated with it, however I am not sure how to > fix this problem. Any help would be greatly appreciated. -- Gregor Maier gregor at icir.org Int. Computer Science Institute (ICSI) gregor at icsi.berkeley.edu 1947 Center St., Ste. 600 http://www.icir.org/gregor/ Berkeley, CA 94704 USA From vern at icir.org Thu Nov 4 15:56:47 2010 From: vern at icir.org (Vern Paxson) Date: Thu, 04 Nov 2010 15:56:47 -0700 Subject: [Bro] TCP Flow Packet Counts In-Reply-To: (Thu, 04 Nov 2010 11:16:21 PDT). Message-ID: <20101104225647.258B436A415@taffy.ICSI.Berkeley.EDU> > I am using version 1.5.1 of bro. The trace I am using is attached as > well as the bro policy file. Thanks for the trace. The problem appears to be that packet counting doesn't work for TCP connections that lack an initial SYN. We have a project right now in considerably extending the analysis framework. So hopefully this will be fixed the next Bro release. Vern From bboe at cs.ucsb.edu Fri Nov 5 10:43:09 2010 From: bboe at cs.ucsb.edu (Bryce Boe) Date: Fri, 5 Nov 2010 10:43:09 -0700 Subject: [Bro] TCP Flow Packet Counts In-Reply-To: <20101104225647.258B436A415@taffy.ICSI.Berkeley.EDU> References: <20101104225647.258B436A415@taffy.ICSI.Berkeley.EDU> Message-ID: Thanks for looking into this Vern. -Bryce On Thu, Nov 4, 2010 at 3:56 PM, Vern Paxson wrote: >> I am using version 1.5.1 of bro. The trace I am using is attached as >> well as the bro policy file. > > Thanks for the trace. ?The problem appears to be that packet counting > doesn't work for TCP connections that lack an initial SYN. > > We have a project right now in considerably extending the analysis framework. > So hopefully this will be fixed the next Bro release. > > ? ? ? ? ? ? ? ?Vern > From juhoon at net.t-labs.tu-berlin.de Mon Nov 8 08:31:57 2010 From: juhoon at net.t-labs.tu-berlin.de (Juhoon Kim) Date: Mon, 08 Nov 2010 17:31:57 +0100 Subject: [Bro] TCP segment retransmission v.s. segment out-of-order Message-ID: <1289233917.21775.55.camel@jkim> Hi all, I'm currently trying to find a method that identifies TCP retransmission and out-of-order in TCP flows from the monitor's point of view. Keeping previous sequence numbers (and cleaning them out after the acknowledgement) in the list and seeing if the current sequence number is already in the list or not, could be a simple approach for identifying retransmissions. However, in this case, we cannot detect segments which are lost before the monitoring point. Thus, I think that following scenario should be considered as a retransmission. [A] - [B] (lost before the analyzer) - [C] - [B] (Retransmission) So, the analyzer sees [A] - [C] - [B]. In this case, when the analyzer processes the segment B (the last segment), the analyzer can realize that the segment is re-sent because the sequence number of B is smaller than the latest seen segment (C). Now, the ambiguousness is caused when we consider the out-of-order. See the following scenario: [A] - [C] - [B] (Delayed) The analyzer sees the same sequence numbers in the same order as the previous scenario shows. However, the segment B here is not a retransmission. Is there any good methods for distinguishing retransmissions from out-of-orders? Any ideas will be very much appreciated. Juhoon From jones at tacc.utexas.edu Mon Nov 8 09:53:11 2010 From: jones at tacc.utexas.edu (William Jones) Date: Mon, 8 Nov 2010 11:53:11 -0600 Subject: [Bro] TCP segment retransmission v.s. segment out-of-order In-Reply-To: <1289233917.21775.55.camel@jkim> References: <1289233917.21775.55.camel@jkim> Message-ID: Tcptrace has code to identify retransmit verse out of order packets. You might find that you can use the same method in bro. -----Original Message----- From: bro-bounces at bro-ids.org [mailto:bro-bounces at bro-ids.org] On Behalf Of Juhoon Kim Sent: Monday, November 08, 2010 10:32 AM To: bro at bro-ids.org Subject: [Bro] TCP segment retransmission v.s. segment out-of-order Hi all, I'm currently trying to find a method that identifies TCP retransmission and out-of-order in TCP flows from the monitor's point of view. Keeping previous sequence numbers (and cleaning them out after the acknowledgement) in the list and seeing if the current sequence number is already in the list or not, could be a simple approach for identifying retransmissions. However, in this case, we cannot detect segments which are lost before the monitoring point. Thus, I think that following scenario should be considered as a retransmission. [A] - [B] (lost before the analyzer) - [C] - [B] (Retransmission) So, the analyzer sees [A] - [C] - [B]. In this case, when the analyzer processes the segment B (the last segment), the analyzer can realize that the segment is re-sent because the sequence number of B is smaller than the latest seen segment (C). Now, the ambiguousness is caused when we consider the out-of-order. See the following scenario: [A] - [C] - [B] (Delayed) The analyzer sees the same sequence numbers in the same order as the previous scenario shows. However, the segment B here is not a retransmission. Is there any good methods for distinguishing retransmissions from out-of-orders? Any ideas will be very much appreciated. Juhoon _______________________________________________ Bro mailing list bro at bro-ids.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From vern at icir.org Mon Nov 8 11:02:18 2010 From: vern at icir.org (Vern Paxson) Date: Mon, 08 Nov 2010 11:02:18 -0800 Subject: [Bro] TCP segment retransmission v.s. segment out-of-order In-Reply-To: <1289233917.21775.55.camel@jkim> (Mon, 08 Nov 2010 17:31:57 +0100). Message-ID: <20101108190218.E637736A42C@taffy.ICSI.Berkeley.EDU> > Is there any good methods for distinguishing retransmissions from > out-of-orders? A fairly robust method involves estimating the connection's minimum RTT and then attributing out-of-sequence packets to reordering if their interarrival time is less than an RTT, and to retransmission otherwise. This will fail for very large reordering intervals, but from measurement studies those are quite rare. For some flows, you can also inspect the IPID field (or I guess timestamps, if present, though I don't know if anyone has tried that). If it normally increases monotonically, then a step backward is a strong indicator of reordering. (Note, we're planning for the next Bro release to contain a bunch of transport analysis, including detection of reordering and retransmission.) Vern From juhoon at net.t-labs.tu-berlin.de Mon Nov 8 11:44:25 2010 From: juhoon at net.t-labs.tu-berlin.de (Juhoon Kim) Date: Mon, 8 Nov 2010 20:44:25 +0100 Subject: [Bro] TCP segment retransmission v.s. segment out-of-order In-Reply-To: <20101108190218.E637736A42C@taffy.ICSI.Berkeley.EDU> References: <1289233917.21775.55.camel@jkim> (Mon, 08 Nov 2010 17:31:57 +0100). <20101108190218.E637736A42C@taffy.ICSI.Berkeley.EDU> Message-ID: <000f01cb7f7d$5a6e03b0$0f4a0b10$@t-labs.tu-berlin.de> Thanks Vern, I just found out that Wireshark uses a fixed amount of time (3ms) instead of the minimum RTT. Do you have any idea where this number came from? Juhoon -----Original Message----- From: Vern Paxson [mailto:vern at ICIR.org] Sent: Monday, November 08, 2010 8:02 PM To: juhoon at net.t-labs.tu-berlin.de Cc: bro at bro-ids.org Subject: Re: [Bro] TCP segment retransmission v.s. segment out-of-order > Is there any good methods for distinguishing retransmissions from > out-of-orders? A fairly robust method involves estimating the connection's minimum RTT and then attributing out-of-sequence packets to reordering if their interarrival time is less than an RTT, and to retransmission otherwise. This will fail for very large reordering intervals, but from measurement studies those are quite rare. For some flows, you can also inspect the IPID field (or I guess timestamps, if present, though I don't know if anyone has tried that). If it normally increases monotonically, then a step backward is a strong indicator of reordering. (Note, we're planning for the next Bro release to contain a bunch of transport analysis, including detection of reordering and retransmission.) Vern From vern at icir.org Mon Nov 8 12:02:57 2010 From: vern at icir.org (Vern Paxson) Date: Mon, 08 Nov 2010 12:02:57 -0800 Subject: [Bro] TCP segment retransmission v.s. segment out-of-order In-Reply-To: <000f01cb7f7d$5a6e03b0$0f4a0b10$@t-labs.tu-berlin.de> (Mon, 08 Nov 2010 20:44:25 +0100). Message-ID: <20101108200257.78760369FC7@taffy.ICSI.Berkeley.EDU> > I just found out that Wireshark uses a fixed amount of time (3ms) instead of > the minimum RTT. > Do you have any idea where this number came from? I would assume they just figured it was a resonable cutoff. Most reordering is indeed quite short-lived, but 3ms strikes me as aggressive in this regard. Tracking the RTT can be a headache, too, though, if the vantage point isn't known to be near a data sender. But it's more sound. Vern From juhoon at net.t-labs.tu-berlin.de Tue Nov 9 03:48:47 2010 From: juhoon at net.t-labs.tu-berlin.de (Juhoon Kim) Date: Tue, 09 Nov 2010 12:48:47 +0100 Subject: [Bro] TCP segment retransmission v.s. segment out-of-order In-Reply-To: References: <1289233917.21775.55.camel@jkim> Message-ID: <1289303327.21775.98.camel@jkim> Hi William, I didn't check the source code of tcptrace yet, but it seems that tcptrace doesn't detect retransmission as I expected. I think tcptrace identifies a segment as a retransmission only when the same sequence number is seen multiple times. Juhoon On Mon, 2010-11-08 at 11:53 -0600, William Jones wrote: > Tcptrace has code to identify retransmit verse out of order packets. You might find that you can use the same method in bro. > > -----Original Message----- > From: bro-bounces at bro-ids.org [mailto:bro-bounces at bro-ids.org] On Behalf Of Juhoon Kim > Sent: Monday, November 08, 2010 10:32 AM > To: bro at bro-ids.org > Subject: [Bro] TCP segment retransmission v.s. segment out-of-order > > Hi all, > > I'm currently trying to find a method that identifies TCP retransmission > and out-of-order in TCP flows from the monitor's point of view. > > Keeping previous sequence numbers (and cleaning them out after the > acknowledgement) in the list and seeing if the current sequence number > is already in the list or not, could be a simple approach for > identifying retransmissions. > > However, in this case, we cannot detect segments which are lost before > the monitoring point. > > Thus, I think that following scenario should be considered as a > retransmission. > > [A] - [B] (lost before the analyzer) - [C] - [B] (Retransmission) > > So, the analyzer sees [A] - [C] - [B]. > > In this case, when the analyzer processes the segment B (the last > segment), the analyzer can realize that the segment is re-sent because > the sequence number of B is smaller than the latest seen segment (C). > > Now, the ambiguousness is caused when we consider the out-of-order. See > the following scenario: > > [A] - [C] - [B] (Delayed) > > The analyzer sees the same sequence numbers in the same order as the > previous scenario shows. However, the segment B here is not a > retransmission. > > Is there any good methods for distinguishing retransmissions from > out-of-orders? > > Any ideas will be very much appreciated. > Juhoon > > > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From juhoon at net.t-labs.tu-berlin.de Wed Nov 10 02:00:14 2010 From: juhoon at net.t-labs.tu-berlin.de (Juhoon Kim) Date: Wed, 10 Nov 2010 11:00:14 +0100 Subject: [Bro] TCP segment retransmission v.s. segment out-of-order In-Reply-To: <20101108190218.E637736A42C@taffy.ICSI.Berkeley.EDU> References: <20101108190218.E637736A42C@taffy.ICSI.Berkeley.EDU> Message-ID: <1289383214.21775.119.camel@jkim> > For some flows, you can also inspect the IPID field IPID sounds very convincing. However, you said "for some flows". Is there any flows that we cannot use IPID for this purpose? > (or I guess timestamps Do you mean the timestamp in the pcap header? or is there any other timestamps written from the end hosts which we can obtain from monitoring point? > (Note, we're planning for the next Bro release to contain a bunch of > transport analysis, When do you expect to release next Bro? > including detection of reordering and retransmission.) I could see some of them in TCPStats_Endpoint and rtt.bro. Is that what you are talking about? Thanks Juhoon From vern at icir.org Wed Nov 10 08:48:12 2010 From: vern at icir.org (Vern Paxson) Date: Wed, 10 Nov 2010 08:48:12 -0800 Subject: [Bro] TCP segment retransmission v.s. segment out-of-order In-Reply-To: <1289383214.21775.119.camel@jkim> (Wed, 10 Nov 2010 11:00:14 +0100). Message-ID: <20101110164812.3976B36A4F0@taffy.ICSI.Berkeley.EDU> > IPID sounds very convincing. However, you said "for some flows". Is > there any flows that we cannot use IPID for this purpose? Right. Some OS's randomize IPID or set it to 0 (for packets sent with DF), which renders the trick unusable. > > (or I guess timestamps > > Do you mean the timestamp in the pcap header? or is there any other > timestamps written from the end hosts which we can obtain from monitoring > point? TCP timestamps, negotiated for some connections. Again, not always doable. Plus, the timestamp format is not standardized. > > (Note, we're planning for the next Bro release to contain a bunch of > > transport analysis, > > When do you expect to release next Bro? We don't have a target date yet. It's a good ways off. > I could see some of them in TCPStats_Endpoint and rtt.bro. Is that what > you are talking about? Yes. Currently just in a branch. Vern From jones at tacc.utexas.edu Wed Nov 10 09:01:22 2010 From: jones at tacc.utexas.edu (William Jones) Date: Wed, 10 Nov 2010 11:01:22 -0600 Subject: [Bro] TCP segment retransmission v.s. segment out-of-order In-Reply-To: <20101110164812.3976B36A4F0@taffy.ICSI.Berkeley.EDU> References: <1289383214.21775.119.camel@jkim> (Wed, 10 Nov 2010 11:00:14 +0100). <20101110164812.3976B36A4F0@taffy.ICSI.Berkeley.EDU> Message-ID: Take a look at tcptrace, http://www.tcptrace.org, it reliable detects retransmits. Bill Jones -----Original Message----- From: bro-bounces at bro-ids.org [mailto:bro-bounces at bro-ids.org] On Behalf Of Vern Paxson Sent: Wednesday, November 10, 2010 10:48 AM To: juhoon at net.t-labs.tu-berlin.de Cc: bro at bro-ids.org Subject: Re: [Bro] TCP segment retransmission v.s. segment out-of-order > IPID sounds very convincing. However, you said "for some flows". Is > there any flows that we cannot use IPID for this purpose? Right. Some OS's randomize IPID or set it to 0 (for packets sent with DF), which renders the trick unusable. > > (or I guess timestamps > > Do you mean the timestamp in the pcap header? or is there any other > timestamps written from the end hosts which we can obtain from monitoring > point? TCP timestamps, negotiated for some connections. Again, not always doable. Plus, the timestamp format is not standardized. > > (Note, we're planning for the next Bro release to contain a bunch of > > transport analysis, > > When do you expect to release next Bro? We don't have a target date yet. It's a good ways off. > I could see some of them in TCPStats_Endpoint and rtt.bro. Is that what > you are talking about? Yes. Currently just in a branch. Vern _______________________________________________ Bro mailing list bro at bro-ids.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From seth at icir.org Wed Nov 10 10:24:36 2010 From: seth at icir.org (Seth Hall) Date: Wed, 10 Nov 2010 13:24:36 -0500 Subject: [Bro] Tracker maintenance Message-ID: Fair warning, I'm doing some maintenance to the ticket tracker today so you may experience some unavailability for a (hopefully) short time. I'll follow up when I'm done with the maintenance. .Seth From seth at icir.org Wed Nov 10 11:31:52 2010 From: seth at icir.org (Seth Hall) Date: Wed, 10 Nov 2010 14:31:52 -0500 Subject: [Bro] Tracker maintenance In-Reply-To: References: Message-ID: <8F63733C-3151-442C-8C1A-BD2E9777A987@icir.org> On Nov 10, 2010, at 1:24 PM, Seth Hall wrote: > Fair warning, I'm doing some maintenance to the ticket tracker Maintenance complete. .Seth From vern at icir.org Wed Nov 10 19:36:15 2010 From: vern at icir.org (Vern Paxson) Date: Wed, 10 Nov 2010 19:36:15 -0800 Subject: [Bro] TCP segment retransmission v.s. segment out-of-order In-Reply-To: (Wed, 10 Nov 2010 11:01:22 CST). Message-ID: <20101111033615.0CD6936A417@taffy.ICSI.Berkeley.EDU> > Take a look at tcptrace, http://www.tcptrace.org, it reliable detects retransmits. As was mentioned earlier in this thread, it treats any packet with a sequence number below a hole as reordering. That's incorrect if packets can be lost upstream from the monitoring point. Vern From estrada.veronica at gmail.com Wed Nov 10 23:58:09 2010 From: estrada.veronica at gmail.com (Veronica Estrada) Date: Thu, 11 Nov 2010 16:58:09 +0900 Subject: [Bro] Dropping packets - How do I leverage multiple core with BRO? Message-ID: Hello BRO professionals, I am using BRO v 1.5.1 to analyze off-line pcap files. When I run BRO on 4Gb pcap file, one CPU core always reaches 100% but the server still has more 15 idle cores. The analysis uses brolite, dpd and detect-protocols. I am afraid BRO is loosing packets. By the way, how can I measure packet dropping? The capture-loss generates this notice: no=CaptureLossSummary na=NOTICE_ALARM_ALWAYS msg=estimated\ rate\ \=\ 0.0082201 tag=@36-6fb3-4a Are this events or bytes? WHy indicates tag? I cannot find any reference to this tag in any of the other logs. By reading the documentation, it seems you don't recommend this metric. Instead, I will be happy to know the number of packets that BRO processed. I cannot find where is this number logged. Best regards Veronica Estrada Nakao's Laboratory Univ. of Tokyo From mcholste at gmail.com Thu Nov 11 07:22:55 2010 From: mcholste at gmail.com (Martin Holste) Date: Thu, 11 Nov 2010 09:22:55 -0600 Subject: [Bro] Dropping packets - How do I leverage multiple core with BRO? In-Reply-To: References: Message-ID: Maybe Bro somehow behaves differently, but I don't think it's possible for anything reading a pcap file to drop packets since the program will read them as it has buffer available. To utilize mutliple cores, try splitting the pcap into multiple files with something like splitcap (splitcap.sourceforge.net) and running parallel Bro processes. I can't tell you whether this will be faster in the end, but I suspect it would be, especially if you have splitcap write its splits to stdout and have Bro read from stdin, avoiding any disk writing. This may take a bit of bash scripting, but I think it's probably possible. Does anyone have something done like this already to send to Veronica? On Thu, Nov 11, 2010 at 1:58 AM, Veronica Estrada wrote: > Hello BRO professionals, > > I am using BRO v 1.5.1 to analyze off-line pcap files. When I run BRO > on 4Gb pcap file, one CPU core always reaches 100% but the server > still has more 15 idle cores. > The analysis uses brolite, dpd and detect-protocols. > > I am afraid BRO is loosing packets. By the way, how can I measure > packet dropping? > > The capture-loss generates this notice: > no=CaptureLossSummary na=NOTICE_ALARM_ALWAYS msg=estimated\ rate\ \=\ > 0.0082201 tag=@36-6fb3-4a > > Are this events or bytes? WHy indicates tag? I cannot find any > reference to this tag in any of the other logs. By reading the > documentation, it seems you don't recommend this metric. > Instead, I will be happy to know the number of packets that BRO > processed. I cannot find where is this number logged. > > Best regards > > Veronica Estrada > Nakao's Laboratory > Univ. of Tokyo > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > From Tyler.Schoenke at colorado.edu Thu Nov 11 09:11:55 2010 From: Tyler.Schoenke at colorado.edu (Tyler T. Schoenke) Date: Thu, 11 Nov 2010 10:11:55 -0700 Subject: [Bro] Dropping packets - How do I leverage multiple core with BRO? In-Reply-To: References: Message-ID: <4CDC23DB.3000608@colorado.edu> This may be possible. I just Googled and saw there is a program called tcprelay that can be used to feed a pcap into an Ethernet interface. You could use tcprelay to feed the pcap into the Click! Modular Router and have Click! load balance the traffic to a Bro cluster with many workers to utilize all your cores. The cluster is quite easy to set up, and the Click! interface config is pretty easy as well. I have a cluster of seven workers running on seven of the cores in my server. The eighth runs Click!. The cluster manager and proxy run on a recycled lab workstation with a big hard drive. If you are interested, I can send a copy of my Click! configuration. It is a modified version of Justin's that was posted to the list a while back. Using this type of setup, you could run the Bro manager, proxy(ies) as well as 12 or 13 worker processes and Click! all on the same server. The only reason I moved my manager and proxy off was to have more workers processing traffic. I think this will work with FreeBSD or Linux. Click! kernel mode requires Linux, but I don't think the load balancing uses kernel drivers. You can grep the notice.log for Dropped to see how much traffic is not being processed. I don't recall the script that logs that, but it is probably drop.bro. I think it is on by default with the cluster config. Tyler -- Tyler Schoenke Network Security Analyst IT Security Office University of Colorado - Boulder On 11/11/2010 12:58 AM, Veronica Estrada wrote: > Hello BRO professionals, > > I am using BRO v 1.5.1 to analyze off-line pcap files. When I run BRO > on 4Gb pcap file, one CPU core always reaches 100% but the server > still has more 15 idle cores. > The analysis uses brolite, dpd and detect-protocols. > > I am afraid BRO is loosing packets. By the way, how can I measure > packet dropping? > > The capture-loss generates this notice: > no=CaptureLossSummary na=NOTICE_ALARM_ALWAYS msg=estimated\ rate\ \=\ > 0.0082201 tag=@36-6fb3-4a > > Are this events or bytes? WHy indicates tag? I cannot find any > reference to this tag in any of the other logs. By reading the > documentation, it seems you don't recommend this metric. > Instead, I will be happy to know the number of packets that BRO > processed. I cannot find where is this number logged. > > Best regards > > Veronica Estrada > Nakao's Laboratory > Univ. of Tokyo > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > > From vern at icir.org Thu Nov 11 09:21:18 2010 From: vern at icir.org (Vern Paxson) Date: Thu, 11 Nov 2010 09:21:18 -0800 Subject: [Bro] Dropping packets - How do I leverage multiple core with BRO? In-Reply-To: (Thu, 11 Nov 2010 16:58:09 +0900). Message-ID: <20101111172118.9B79D36A4F5@taffy.ICSI.Berkeley.EDU> > I am using BRO v 1.5.1 to analyze off-line pcap files. When I run BRO > on 4Gb pcap file, one CPU core always reaches 100% but the server > still has more 15 idle cores. Right, because unless you set up a cluster, Bro runs as a single process. > I am afraid BRO is loosing packets. By the way, how can I measure > packet dropping? It will not lose packets when reading from a trace off-line. > The capture-loss generates this notice: > no=CaptureLossSummary na=NOTICE_ALARM_ALWAYS msg=estimated\ rate\ \=\ > 0.0082201 tag=@36-6fb3-4a That's its estimate of what was lost during the original packet capture (i.e., the recording of the trace). > Are this events or bytes? Unless you redef CaptureLoss::report_byte_based_estimates=T, the estimates are events. > WHy indicates tag? The tag is for use when operating a cluster; you can ignore it here. > By reading the > documentation, it seems you don't recommend this metric. Right - events are more reliable than byte-based loss estimations. > Instead, I will be happy to know the number of packets that BRO > processed. I cannot find where is this number logged. This isn't reported, but per the above, it will be the entire trace file without any loss during its reading of it. Vern From jebrahimi at bivio.net Thu Nov 11 10:12:25 2010 From: jebrahimi at bivio.net (Joel Ebrahimi) Date: Thu, 11 Nov 2010 10:12:25 -0800 Subject: [Bro] Bro Cluster on the Bivio Platform Message-ID: I recently built and tested Bro Cluster for the Bivio Platform for some of our customers and wanted to share the information. The cluster version of Bro is a very native fit for the Bivio architecture. The internals of the Bivio platform on a single Bivio 7562 can be thought of as a load balancer and 12 separate Linux systems (this can scale to 48 systems in a single logical unit). The Linux systems have their own communication plane within the Bivio system that is separate from the packet acquisition path and can use this to talk to the workers, proxies, and the manager. The shared file system also allows for easy setup. Below are the steps I used to setup the system and Bro Cluster. I also attached my node.cfg for a Bivio 7562, this file can be edited so that it reflects the number of cpu cores that will be running systems for Bro. Installation -------------------------- 1. Unzip Bro tar -zxvf bro-1.5-release.tar.gz 2. Change into the Bro directory cd bro-1.5.1/ 3. Configure Bro with desired options ./configure --disable-select-loop --enable-cluster 4. Build Bro make 5. Install Bro with Broctl make install-broctl System Configuration --------------------------- 1. Turn off strict key checking to avoid key prompts when logging into Bro worker cpus vi /etc/ssh/ssh_config add StrictHostKeyChecking no 2. Generate public/private key ssh-keygen -t rsa -f /root/.ssh/id_rsa hit return twice for a blank passphrase 3. Add it to the authorized keys cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys2 4. Setup your manager,proxy, and worker nodes in your node.cfg configuration file # $Id: node.cfg,v 1.1 2010/11/05 19:49:46 jebrahimi Exp $ # # Node configuration # [manager] type=manager host=CPU-X [proxy-1] type=proxy host=CPU-X [worker-1] type=worker host=CPU-1c0 interface=default [worker-2] type=worker host=CPU-1c1 interface=default [worker-3] type=worker host=CPU-2c0 interface=default [worker-4] type=worker host=CPU-2c1 interface=default [worker-5] type=worker host=CPU-3c0 interface=default [worker-6] type=worker host=CPU-3c1 interface=default [worker-7] type=worker host=CPU-4c0 interface=default [worker-8] type=worker host=CPU-4c1 interface=default [worker-9] type=worker host=CPU-5c0 interface=default [worker-10] type=worker host=CPU-5c1 interface=default [worker-11] type=worker host=CPU-6c0 interface=default [worker-12] type=worker host=CPU-6c1 interface=default 5. Edit your networks.cfg and broctl.cfg in /usr/local/bro/etc/ 6. You will need to add the Bro binaries to you Path export PATH="$PATH:/usr/local/bro/bin" 7. Install workers and proxies broctl install Running Bro ----------------- 1. Since we are running Bro through the cluster shell and not Bivios nrsp we will need to force on load sharing to the APC CPUs nrsp loadshare all on 2. Add the crontab entry for some required Bro tasks, enter cron crontab -e then add 0-59/5 * * * * /usr/local/bro/bin/broctl cron 3. Start Bro broctl start // Joel Joel Ebrahimi Solutions Architect Bivio Networks Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20101111/e497526a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: node.cfg Type: application/octet-stream Size: 892 bytes Desc: node.cfg Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20101111/e497526a/attachment.obj From jcarr at andrew.cmu.edu Thu Nov 11 14:33:59 2010 From: jcarr at andrew.cmu.edu (Jason Carr) Date: Thu, 11 Nov 2010 17:33:59 -0500 Subject: [Bro] Notice only every four hours Message-ID: <9A54B4A5-A6B0-476B-A820-DDF3AC850ED9@andrew.cmu.edu> I'm writing to a global table with two items in a set (global blah: set[addr,string] &write_expire = 4 hrs;) I'm adding items into the table like this: add blah[a,b];, then adding a notice for an external parser to deal with. Is there any way to only send the notice every four hours? Thanks guys, Jason From vallentin at icir.org Thu Nov 11 14:53:32 2010 From: vallentin at icir.org (Matthias Vallentin) Date: Thu, 11 Nov 2010 14:53:32 -0800 Subject: [Bro] Notice only every four hours In-Reply-To: <9A54B4A5-A6B0-476B-A820-DDF3AC850ED9@andrew.cmu.edu> References: <9A54B4A5-A6B0-476B-A820-DDF3AC850ED9@andrew.cmu.edu> Message-ID: <20101111225332.GG34938@icsi.berkeley.edu> > Is there any way to only send the notice every four hours? Assuming you want to report a single entry every 4 hours, a common idiom is to maintain a separate set that tracks the entries already reported: global blah_reported: set[addr,string] &create_expire = 4 hrs; And in your event handler: if ([a,b] !in blah_reported) { NOTICE(...); add blah_reported[a,b]; } If you want to instead elicit a list of Notice every 4 hours, you would need to implement some notice buffering. (Depending on your analysis, this could be quite memory-intensive and thus requires care.) In this setting, you could let a dummy variable expire and flush the buffer with notices in the expiration function - scan.bro uses a similar technique. Matthias From estrada.veronica at gmail.com Fri Nov 12 08:01:14 2010 From: estrada.veronica at gmail.com (Veronica Estrada) Date: Sat, 13 Nov 2010 01:01:14 +0900 Subject: [Bro] Dropping packets - How do I leverage multiple core with BRO? In-Reply-To: <4CDC23DB.3000608@colorado.edu> References: <4CDC23DB.3000608@colorado.edu> Message-ID: Thank you for your detailed answer. I am doing analysis on terabytes of data that is why i need load balance. Could you send me the config? Veronica On Fri, Nov 12, 2010 at 2:11 AM, Tyler T. Schoenke wrote: > This may be possible. ?I just Googled and saw there is a program called > tcprelay that can be used to feed a pcap into an Ethernet interface. > You could use tcprelay to feed the pcap into the Click! Modular Router > and have Click! load balance the traffic to a Bro cluster with many > workers to utilize all your cores. > > The cluster is quite easy to set up, and the Click! interface config is > pretty easy as well. ?I have a cluster of seven workers running on seven > of the cores in my server. ?The eighth runs Click!. ?The cluster manager > and proxy run on a recycled lab workstation with a big hard drive. > > If you are interested, I can send a copy of my Click! configuration. ?It > is a modified version of Justin's that was posted to the list a while back. > > Using this type of setup, you could run the Bro manager, proxy(ies) as > well as 12 or 13 worker processes and Click! all on the same server. > The only reason I moved my manager and proxy off was to have more > workers processing traffic. ?I think this will work with FreeBSD or > Linux. ?Click! kernel mode requires Linux, but I don't think the load > balancing uses kernel drivers. > > You can grep the notice.log for Dropped to see how much traffic is not > being processed. ?I don't recall the script that logs that, but it is > probably drop.bro. ?I think it is on by default with the cluster config. > > Tyler > > -- > Tyler Schoenke > Network Security Analyst > IT Security Office > University of Colorado - Boulder > > > On 11/11/2010 12:58 AM, Veronica Estrada wrote: >> Hello BRO professionals, >> >> I am using BRO v 1.5.1 to analyze off-line pcap files. When I run BRO >> on 4Gb pcap file, one CPU core always reaches 100% but the server >> still has more 15 idle cores. >> The analysis uses brolite, dpd and detect-protocols. >> >> I am afraid BRO is loosing packets. By the way, how can I measure >> packet dropping? >> >> The capture-loss generates this notice: >> no=CaptureLossSummary na=NOTICE_ALARM_ALWAYS msg=estimated\ rate\ \=\ >> 0.0082201 tag=@36-6fb3-4a >> >> Are this events or bytes? WHy indicates tag? I cannot find any >> reference to this tag in any of the other logs. By reading the >> documentation, it seems you don't recommend this metric. >> Instead, I will be happy to know the number of packets that BRO >> processed. I cannot find where is this number logged. >> >> Best regards >> >> Veronica Estrada >> Nakao's Laboratory >> Univ. of Tokyo >> _______________________________________________ >> Bro mailing list >> bro at bro-ids.org >> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro >> >> > From JAzoff at uamail.albany.edu Fri Nov 12 08:06:04 2010 From: JAzoff at uamail.albany.edu (Justin Azoff) Date: Fri, 12 Nov 2010 11:06:04 -0500 Subject: [Bro] Dropping packets - How do I leverage multiple core with BRO? In-Reply-To: <4CDC23DB.3000608@colorado.edu> References: <4CDC23DB.3000608@colorado.edu> Message-ID: <20101112160604.GY26932@datacomm.albany.edu> On Thu, Nov 11, 2010 at 12:11:55PM -0500, Tyler T. Schoenke wrote: > This may be possible. I just Googled and saw there is a program called > tcprelay that can be used to feed a pcap into an Ethernet interface. > You could use tcprelay to feed the pcap into the Click! Modular Router > and have Click! load balance the traffic to a Bro cluster with many > workers to utilize all your cores. Click can read directly from a pcap file: http://read.cs.ucla.edu/click/elements/fromdump using that instead of FromDevice should work better than tcprelay. -- -- Justin Azoff -- Network Security & Performance Analyst From Tyler.Schoenke at colorado.edu Fri Nov 12 08:08:45 2010 From: Tyler.Schoenke at colorado.edu (Tyler T. Schoenke) Date: Fri, 12 Nov 2010 09:08:45 -0700 Subject: [Bro] Dropping packets - How do I leverage multiple core with BRO? In-Reply-To: References: <4CDC23DB.3000608@colorado.edu> Message-ID: <4CDD668D.20206@colorado.edu> I forgot that I already put it on the Wiki. http://www.bro-ids.org/wiki/index.php/ClusterFrontendClickModularRouter Tyler On 11/12/2010 09:01 AM, Veronica Estrada wrote: > Thank you for your detailed answer. I am doing analysis on terabytes > of data that is why i need load balance. > > Could you send me the config? > Veronica > > > On Fri, Nov 12, 2010 at 2:11 AM, Tyler T. Schoenke > wrote: > >> This may be possible. I just Googled and saw there is a program called >> tcprelay that can be used to feed a pcap into an Ethernet interface. >> You could use tcprelay to feed the pcap into the Click! Modular Router >> and have Click! load balance the traffic to a Bro cluster with many >> workers to utilize all your cores. >> >> The cluster is quite easy to set up, and the Click! interface config is >> pretty easy as well. I have a cluster of seven workers running on seven >> of the cores in my server. The eighth runs Click!. The cluster manager >> and proxy run on a recycled lab workstation with a big hard drive. >> >> If you are interested, I can send a copy of my Click! configuration. It >> is a modified version of Justin's that was posted to the list a while back. >> >> Using this type of setup, you could run the Bro manager, proxy(ies) as >> well as 12 or 13 worker processes and Click! all on the same server. >> The only reason I moved my manager and proxy off was to have more >> workers processing traffic. I think this will work with FreeBSD or >> Linux. Click! kernel mode requires Linux, but I don't think the load >> balancing uses kernel drivers. >> >> You can grep the notice.log for Dropped to see how much traffic is not >> being processed. I don't recall the script that logs that, but it is >> probably drop.bro. I think it is on by default with the cluster config. >> >> Tyler >> >> -- >> Tyler Schoenke >> Network Security Analyst >> IT Security Office >> University of Colorado - Boulder >> >> >> On 11/11/2010 12:58 AM, Veronica Estrada wrote: >> >>> Hello BRO professionals, >>> >>> I am using BRO v 1.5.1 to analyze off-line pcap files. When I run BRO >>> on 4Gb pcap file, one CPU core always reaches 100% but the server >>> still has more 15 idle cores. >>> The analysis uses brolite, dpd and detect-protocols. >>> >>> I am afraid BRO is loosing packets. By the way, how can I measure >>> packet dropping? >>> >>> The capture-loss generates this notice: >>> no=CaptureLossSummary na=NOTICE_ALARM_ALWAYS msg=estimated\ rate\ \=\ >>> 0.0082201 tag=@36-6fb3-4a >>> >>> Are this events or bytes? WHy indicates tag? I cannot find any >>> reference to this tag in any of the other logs. By reading the >>> documentation, it seems you don't recommend this metric. >>> Instead, I will be happy to know the number of packets that BRO >>> processed. I cannot find where is this number logged. >>> >>> Best regards >>> >>> Veronica Estrada >>> Nakao's Laboratory >>> Univ. of Tokyo >>> _______________________________________________ >>> Bro mailing list >>> bro at bro-ids.org >>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro >>> >>> >>> >> From estrada.veronica at gmail.com Fri Nov 12 08:12:36 2010 From: estrada.veronica at gmail.com (Veronica Estrada) Date: Sat, 13 Nov 2010 01:12:36 +0900 Subject: [Bro] Dropping packets - How do I leverage multiple core with BRO? In-Reply-To: <20101112160604.GY26932@datacomm.albany.edu> References: <4CDC23DB.3000608@colorado.edu> <20101112160604.GY26932@datacomm.albany.edu> Message-ID: That works great for me. Actually, installing tcprelay in the machine may be problematic. VE On Sat, Nov 13, 2010 at 1:06 AM, Justin Azoff wrote: > On Thu, Nov 11, 2010 at 12:11:55PM -0500, Tyler T. Schoenke wrote: >> This may be possible. ?I just Googled and saw there is a program called >> tcprelay that can be used to feed a pcap into an Ethernet interface. >> You could use tcprelay to feed the pcap into the Click! Modular Router >> and have Click! load balance the traffic to a Bro cluster with many >> workers to utilize all your cores. > > Click can read directly from a pcap file: > > http://read.cs.ucla.edu/click/elements/fromdump > > using that instead of FromDevice should work better than tcprelay. > > -- > -- Justin Azoff > -- Network Security & Performance Analyst > From tarupp at fnal.gov Tue Nov 16 07:09:06 2010 From: tarupp at fnal.gov (Tim Rupp) Date: Tue, 16 Nov 2010 09:09:06 -0600 Subject: [Bro] recipe for log rotating? Message-ID: <4CE29E92.4060404@fnal.gov> Hi folks, I was wondering if anyone had a recipe for changing the log rotate script to rotate bro logs like regular log rotate does notice.log notice.log.1 notice.log.2 notice.log.3 etc vs notice.log-10-11-15_13.00.00 notice.log-10-11-15_14.00.00 notice.log-10-11-15_15.00.00 notice.log-10-11-15_16.00.00 etc And extra points for cleanup of "old" logs. Thought I'd ask before I did it myself. Thanks, -Tim From seth at icir.org Tue Nov 16 08:07:36 2010 From: seth at icir.org (Seth Hall) Date: Tue, 16 Nov 2010 11:07:36 -0500 Subject: [Bro] recipe for log rotating? In-Reply-To: <4CE29E92.4060404@fnal.gov> References: <4CE29E92.4060404@fnal.gov> Message-ID: <4FBC8199-0C2A-4C34-B899-4A1B234EC547@icir.org> On Nov 16, 2010, at 10:09 AM, Tim Rupp wrote: > Hi folks, > > I was wondering if anyone had a recipe for changing the log rotate > script to rotate bro logs like regular log rotate does > > notice.log > notice.log.1 > notice.log.2 > notice.log.3 I'm thinking about how to implement this, but I had some questions. Are you using BroControl so your logs are being put into directories by day? How do you see these log names working in that context? Would each day have logs named like: *.0, *.2, *.3, ..., *.23? Or are you asking about creating logs named this way outside of the context of BroControl? .Seth From cjmanders at gmail.com Tue Nov 16 08:17:42 2010 From: cjmanders at gmail.com (Christopher Jay Manders) Date: Tue, 16 Nov 2010 08:17:42 -0800 Subject: [Bro] recipe for log rotating? In-Reply-To: <4CE29E92.4060404@fnal.gov> References: <4CE29E92.4060404@fnal.gov> Message-ID: <4CE2AEA6.9070100@gmail.com> Hi Tim, I use logrotate. It was made for Linux, but is ported to FreeBSD (/usr/ports/sysutils/logrotate/). Very configurable for log management. Check out this resource for an example config and online documentation: http://www.linuxconfig.org/Logrotate HTH Cheers! Christopher On 11/16/2010 07:09 AM, Tim Rupp wrote: > Hi folks, > > I was wondering if anyone had a recipe for changing the log rotate > script to rotate bro logs like regular log rotate does > > notice.log > notice.log.1 > notice.log.2 > notice.log.3 > etc > > > vs > > notice.log-10-11-15_13.00.00 > notice.log-10-11-15_14.00.00 > notice.log-10-11-15_15.00.00 > notice.log-10-11-15_16.00.00 > etc > > > And extra points for cleanup of "old" logs. > > Thought I'd ask before I did it myself. > > Thanks, > -Tim > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From tarupp at fnal.gov Tue Nov 16 08:28:20 2010 From: tarupp at fnal.gov (Tim Rupp) Date: Tue, 16 Nov 2010 10:28:20 -0600 Subject: [Bro] recipe for log rotating? In-Reply-To: <4FBC8199-0C2A-4C34-B899-4A1B234EC547@icir.org> References: <4CE29E92.4060404@fnal.gov> <4FBC8199-0C2A-4C34-B899-4A1B234EC547@icir.org> Message-ID: <4CE2B124.9010102@fnal.gov> Well, right now I'm just using straight bro (the binary) because I'm in the middle of debugging a script, but ultimately it will move to brocontrol. I have only limited experience with BroControl at this point though (I ran it and started a script) I haven't experienced BroControl's handling of log files yet. I guess I'm just looking to simulate what regular old linux does with logs and logrotate; everything goes into one directory, or a subset of that one directory (for instance httpd logs in the subdirectory /var/log/httpd/) and then logrotate coming around and making .1, .2, etc at some interval. It'd be equally acceptable to me if I could just change the bro log file name to not be a timestamp, and then have logrotate work like it does naturally. Can I redef the build_name function in rotate logs and just return a string like "messages" and then bro would create a regular file called "messages" without the extra timestamp text, filename suffix, etc?? If I were to let logrotate handle rotating of the bro log, I'd also want to tell bro to never rotate it's own file, and then in the logrotate config specify "copytruncate" to prevent bro from losing any open handles to it's log file right? I approached the log rotate question as a function of bro, but maybe in my case I would be happy with what I described above? -Tim Seth Hall wrote: > On Nov 16, 2010, at 10:09 AM, Tim Rupp wrote: > >> Hi folks, >> >> I was wondering if anyone had a recipe for changing the log rotate >> script to rotate bro logs like regular log rotate does >> >> notice.log >> notice.log.1 >> notice.log.2 >> notice.log.3 > > I'm thinking about how to implement this, but I had some questions. Are you using BroControl so your logs are being put into directories by day? How do you see these log names working in that context? Would each day have logs named like: *.0, *.2, *.3, ..., *.23? > > Or are you asking about creating logs named this way outside of the context of BroControl? > > .Seth From seth at icir.org Tue Nov 16 11:49:36 2010 From: seth at icir.org (Seth Hall) Date: Tue, 16 Nov 2010 14:49:36 -0500 Subject: [Bro] recipe for log rotating? In-Reply-To: <4CE2B124.9010102@fnal.gov> References: <4CE29E92.4060404@fnal.gov> <4FBC8199-0C2A-4C34-B899-4A1B234EC547@icir.org> <4CE2B124.9010102@fnal.gov> Message-ID: On Nov 16, 2010, at 11:28 AM, Tim Rupp wrote: > Can I redef the build_name function in rotate logs and just return a string like "messages" and then bro would create a regular file called "messages" without the extra timestamp text, filename suffix, etc?? Instead of doing that, you should be able to just not load the rotate-logs.bro script. This changes if you are running broctl though because there is some small amount of log rotation logic contained there and rotate-logs.bro is loaded by some of the broctl scripts. Just be aware that the all.bro and the (deprecated) brolite.bro script both load rotate-logs.bro. > If I were to let logrotate handle rotating of the bro log, I'd also want to tell bro to never rotate it's own file, and then in the logrotate config specify "copytruncate" to prevent bro from losing any open handles to it's log file right? After looking at the logrotate man page, I think you are correct. If you find that that option works with Bro, could you please report back? > I approached the log rotate question as a function of bro, but maybe in my case I would be happy with what I described above? When you make the move to BroControl, you may find that you are actually just fine with how it does log rotation. I haven't heard any complaints about how it manages the logs at least. I think it's probably worthwhile to think of the logs that Bro outputs as different from your system logs since that's the primary output of the application. The logs are more equivalent to the database that a web application might use and less comparable to the logs that the web server running the web application outputs. .Seth From soehlert at ncsa.uiuc.edu Mon Nov 22 14:51:37 2010 From: soehlert at ncsa.uiuc.edu (Sam Oehlert) Date: Mon, 22 Nov 2010 16:51:37 -0600 (CST) Subject: [Bro] Make Errors Bro 1.5.1 CentOS 5.5 In-Reply-To: <1949600764.4849.1290466149269.JavaMail.root@zimbra-1.ncsa.uiuc.edu> Message-ID: <194497165.4859.1290466297453.JavaMail.root@zimbra-1.ncsa.uiuc.edu> I am trying to setup bro on a CentOS 5.5 server. I am running into problems once I hit the make step. I get /opt/bro/src/Val.cc:2537: undefined reference to 'debug_logger' Val.o: In function 'MutableVal::LoggingAccess() const': /opt/bro/src/Val.h:458: undefined reference to 'debug_logger' collect2: ld returned 1 exit status make[3]: ***[bro] Error 1 make[3]: Leaving directory '/opt/bro-1.5.1/src' make[2]: ***[all] Error 2 make[2]: Leaving directory '/opt/bro-1.5.1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/opt/bro-1.5.1/src' make: *** [all] Error 2 This was a default install of CentOS, nothing but updates done to it so far. The only things I added based on previous installations of bro were: autoconf bison byacc flex gcc gcc-c++ libtool ncurses-devel openssl openssl-devel python python-devel python-tools ruby I also installed GeoIP-devel-1.4.5.1 GeoIP-1.4.5.1 libpcap-0.9.7 Any help would be great. Thanks, Sam From soehlert at ncsa.uiuc.edu Mon Nov 22 15:24:53 2010 From: soehlert at ncsa.uiuc.edu (Sam Oehlert) Date: Mon, 22 Nov 2010 17:24:53 -0600 (CST) Subject: [Bro] Make Errors Bro 1.5.1 CentOS 5.5 In-Reply-To: <194497165.4859.1290466297453.JavaMail.root@zimbra-1.ncsa.uiuc.edu> Message-ID: <1932902895.5048.1290468293622.JavaMail.root@zimbra-1.ncsa.uiuc.edu> After a make clean and trying again, everything seems to be just fine. Not sure what caused it, but it is working now. Sam ----- Original Message ----- From: "Sam Oehlert" To: "bro" Sent: Monday, November 22, 2010 4:51:37 PM Subject: [Bro] Make Errors Bro 1.5.1 CentOS 5.5 I am trying to setup bro on a CentOS 5.5 server. I am running into problems once I hit the make step. I get /opt/bro/src/Val.cc:2537: undefined reference to 'debug_logger' Val.o: In function 'MutableVal::LoggingAccess() const': /opt/bro/src/Val.h:458: undefined reference to 'debug_logger' collect2: ld returned 1 exit status make[3]: ***[bro] Error 1 make[3]: Leaving directory '/opt/bro-1.5.1/src' make[2]: ***[all] Error 2 make[2]: Leaving directory '/opt/bro-1.5.1/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/opt/bro-1.5.1/src' make: *** [all] Error 2 This was a default install of CentOS, nothing but updates done to it so far. The only things I added based on previous installations of bro were: autoconf bison byacc flex gcc gcc-c++ libtool ncurses-devel openssl openssl-devel python python-devel python-tools ruby I also installed GeoIP-devel-1.4.5.1 GeoIP-1.4.5.1 libpcap-0.9.7 Any help would be great. Thanks, Sam _______________________________________________ Bro mailing list bro at bro-ids.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From estrada.veronica at gmail.com Wed Nov 24 07:25:36 2010 From: estrada.veronica at gmail.com (Veronica Estrada) Date: Thu, 25 Nov 2010 00:25:36 +0900 Subject: [Bro] Fragmentation and TCP overlapping Issues Message-ID: Hello everyone, First of all, tomorrow is thanksgiving and I would like to thank all of you for all the feedback I've always received to my posts. I continue with my research on anomalies, now focus on evasion techniques, and I need to ask you some help to understand how BRO deals with fragmentation and TCP overlapping issues. For reference, I am using Bro 1.5.1 in offline analysis. 1. Although I am loading "frag", I am not receiving any event related with fragmentation. What could be wrong? libpcap library? my BRO version? 2. What are the possible events triggered by weird analyzer related with tcp overlapping? (because I am not getting any of them although I think I should see them on my trace) 3. TCP overlapping problems may generate "partial_ftp_request", "partial_RPC_request" or other partial events? and also confuse BRO on how the connection should be flagged? For example a connection with flag "S0", no reply seen could be related with TCP overlapping problems? 4. How does BRO perform TCP reassembly? I mean, is the traffic on ALL ports reassembled? Is there any way to apply a default policy for doing TCP reassembly? Like Policy First or Last or Unix? 5. There is an "active mapping" function to improve TCP reassembly. Can we define the host profile database without this active function? 6. Can we configure the size of the reassembly buffer? I read in historical msg (from 2006) there wasn't such config and BRO presented a vulnerability against an adversary trying to exhaust memory, is this a current possibility? 7. By doing offline analysis, I understood that BRO will analyze all the packets without loss even if the CPU is running at 100%. Still, I need information about dropping packets for other reasons. For example, if BRO encounters TCP overlapping, Does it drop all the packets? Choose some of them? Are these actions log somewhere? The same with fragmentations issues. Where can I check the portion of fragments that where reassembled? how many frames discarded, etc? 8. I am not seeing any difference in bro logs when I analyze 2 pcap files. One file contains some malformed packet at the end and wireshark says "the packet is bigger than 65535", the other pcap file is the same file but truncated using editcap to avoid this "malformed packet" (if I check the hex using hd, the part truncated represents 850MB ). All the logs of BRO when input is one file or the other are identical. Is this the expected result? Veronica Estrada Nakao Lab. Network System Research Group University of Tokyo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20101125/253800a8/attachment.html From renaud.luca at gmail.com Wed Nov 24 15:30:12 2010 From: renaud.luca at gmail.com (Luca Renaud) Date: Wed, 24 Nov 2010 23:30:12 +0000 Subject: [Bro] Unable to compile Bro on Solaris 11 Express. Message-ID: I was unable to compile Bro-1.5.1 on Solaris 11 Express.Below are the last lines of warnings make gave me. ./configure did not show any problem. gcc -g -O2 -I/include -I/usr/include -o hf hf.o setsignal.o version.o -lreadline -lz -lpcap -lpcap -lssl -lcrypto -lnsl -lsocket -lpcap -ltermcap Undefined first referenced symbol in file _res hf.o ld: fatal: symbol referencing errors. No output written to hf collect2: ld returned 1 exit status make[4]: *** [hf] Error 1 make[4]: Leaving directory `/home/abar/bro-1.5.1/aux/hf' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/abar/bro-1.5.1/aux' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/abar/bro-1.5.1/aux' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/abar/bro-1.5.1' make: *** [all] Error 2 From robin at icir.org Mon Nov 29 22:22:23 2010 From: robin at icir.org (Robin Sommer) Date: Mon, 29 Nov 2010 22:22:23 -0800 (PST) Subject: [Bro] Out of the office Message-ID: <201011300622.oAU6MNgx029245@fruitcake.ICSI.Berkeley.EDU> Thanks for your mail. Please note that as I'm currently out on travel, replies may take a bit longer than usual. Best regards, Robin -- Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org