From dalbrech at illinois.edu Mon Mar 2 08:25:42 2009 From: dalbrech at illinois.edu (dalbrech at illinois.edu) Date: Mon, 2 Mar 2009 10:25:42 -0600 (CST) Subject: [Bro] A more parallel Bro Message-ID: <20090302102542.BYE93712@expms4.cites.uiuc.edu> Robin Sommer wrote: > On Wed, Feb 25, 2009 at 14:26 -0600, dalbrech at illinois.edu wrote: > >> I've been doing some performance profiling on Bro. > > Interesting! Do you have any results you could share? I saw Vern's talk a while back at UIUC about how Bro works. As I recall, there were three major components: 1. A packet capture engine, based on libpcap, which makes use of BPF to selectively discard packets as early as practical (to reduce the overall quantity of traffic), 2. Protocol parsers, which turn blocks of data from the network into semantically-meaningful PDU-like data structures, and 3. An event engine, which applies constraints to the lexed protocol data, and possibly raises alarms if the traffic is suspicious or otherwise "interesting". My group initially decided to pursue protocol parsing, because our micro- benchmarks (many of which appeared in our RAID '08 paper) showed that protocol parser-generators (e.g. binpac and Nikita et al.'s GAPA) leave significant performance on the table versus a hand-coded parser. In particular, binpac's use of C++ objects to represent PDUs really suffers on protocols which feature small, deeply-nested messages, like DNS. However, the ultimate question is how much the performance gap between a hand-coded parser vs. a machine-generated one matters in the context of a real system. So I built a simple tool I call "dns-packet-gen", which generates pathological DNS packets constructed for their difficulty in parsing. The tool emits pcap traces containing DNS traffic with many records (50+), all of which feature deeply-recursive DNS names. For the record, Wireshark routinely took an hour or more to load traces of 1M of these packets. Based on my understanding of the Bro code, it looks like parsing "normal" DNS traffic (real DNS scraped from my own web browsing) only accounts for 4-5% of all CPU time (I used Shark on OS X with a debug build, and checked the sampled CPU time of all descendants of UDP_Analyzer::DeliverPacket()). I'm using a version of the "detect backdoors" script which includes DPD, which might have skewed the results a little. (If anyone has comments on this, I'd appreciate hearing them). In either case, my bad DNS traffic only pushed the binpac-based analyzers up to 13-14% of CPU time, which is still comparatively tiny in relation to the EventMgr's CPU time. What I take away from this is that, even if binpac is slow, it's not the piece that most demands attention. So I started thinking about the systems-level issues (the Shunt paper took this same direction), and realized the main event loop is single-threaded. And that got me to where I am today :-) > >> I'm wondering what the ICSI folks' position is on threads vs. clustering. > > In short: we consider them orthogonal and are pursuing both. :-) > > To elaborate a bit: The cluster is the approach that can provide > significantly increased performance right now; ignoring a few > implementation glitches we still need to sort out, it's working and > ready to use[1]. The cluster is also an approach that will work > long-term: there will always be limits to what a single box can do > (multi-core or not) and the cluster offers the capability to go > beyond that. You're right about scale, modulo communications issues. However, I think it's important for a large-scale system to be designed in such a way as to gain more performance as the architecture guys throw faster and faster chips over the wall. The way I read the tea leaves, the number of CPU cores in commodity PCs isn't dropping anytime soon, so software that isn't written with multi- threaded event loops is going to hit a performance wall even as CPUs get faster. > > That said, we are in parallel (no pun intended :) working on a > multi-threaded Bro implementation. While we have already made quite > a bit of progress on that, that will however still take a bit to get > into any kind of usable state; we need to restructure Bro internally > quite a bit to exploit its concurrency potential. Once finished > though, we expect Bro's performance to scale pretty well with the > number of available cores (not considering other aspects of the > hardware which might turn into bottlenecks at some point). The > Sarnoff paper has some of the basic ideas for the multi-threaded > Bro, and there'll be an extended journal version of that coming out > soon with more details on the parallel execution model (let me know > if you'd to like to get a draft). > > Does that answer your question? If you have any particular thoughts > on either clustering or the multi-threaded Bro, I'd be happy to hear > them. I haven't explored how threadable Bro would be, but it seems you're already on it. Truthfully, I spent a few weeks picking through the code to convince myself I knew roughly how to profile it; I'm no expert on Bro internals. I'm going to have a chat with Nikita soon (my academic adviser) to see what he thinks about all this, and I'll be in touch. Please send the draft of the Sarnoff paper to my UIUC email address; I'd love to have a look. I'm wondering how you plan to address cache behavior in your multi-threaded implementation of Bro. Obviously, this is a really hard problem, and I'm not sure how well-studied it is in the literature, especially in the context of IDS. Fortunately, I have a lot of friends here that do high-performance computing work (their long-range research agenda includes a 3000-core CPU tapeout), so I'll talk to them about it. David From jones at tacc.utexas.edu Mon Mar 2 09:41:43 2009 From: jones at tacc.utexas.edu (William L. Jones) Date: Mon, 2 Mar 2009 11:41:43 -0600 Subject: [Bro] A more parallel Bro In-Reply-To: <20090302102542.BYE93712@expms4.cites.uiuc.edu> References: <20090302102542.BYE93712@expms4.cites.uiuc.edu> Message-ID: <0E07074B82CE4B4A9982802A8484B69672791584E7@EXCHANGE2K7.tacc.utexas.edu> It is possible to take advantage of muti cpu system with the current bro. I am running 4 cpu test system now that runs 4 bro instances on 10GigE interface using a modification of the odd/even filter that was suggest on bro wiki in the User Manual: Performance Tuning section. It is spreading the load across the cpus. Bill Jones -----Original Message----- From: bro-bounces at ICSI.Berkeley.EDU [mailto:bro-bounces at ICSI.Berkeley.EDU] On Behalf Of dalbrech at illinois.edu Sent: Monday, March 02, 2009 10:26 AM To: bro at ICSI.Berkeley.EDU Subject: Re: [Bro] A more parallel Bro Robin Sommer wrote: > On Wed, Feb 25, 2009 at 14:26 -0600, dalbrech at illinois.edu wrote: > >> I've been doing some performance profiling on Bro. > > Interesting! Do you have any results you could share? I saw Vern's talk a while back at UIUC about how Bro works. As I recall, there were three major components: 1. A packet capture engine, based on libpcap, which makes use of BPF to selectively discard packets as early as practical (to reduce the overall quantity of traffic), 2. Protocol parsers, which turn blocks of data from the network into semantically-meaningful PDU-like data structures, and 3. An event engine, which applies constraints to the lexed protocol data, and possibly raises alarms if the traffic is suspicious or otherwise "interesting". My group initially decided to pursue protocol parsing, because our micro- benchmarks (many of which appeared in our RAID '08 paper) showed that protocol parser-generators (e.g. binpac and Nikita et al.'s GAPA) leave significant performance on the table versus a hand-coded parser. In particular, binpac's use of C++ objects to represent PDUs really suffers on protocols which feature small, deeply-nested messages, like DNS. However, the ultimate question is how much the performance gap between a hand-coded parser vs. a machine-generated one matters in the context of a real system. So I built a simple tool I call "dns-packet-gen", which generates pathological DNS packets constructed for their difficulty in parsing. The tool emits pcap traces containing DNS traffic with many records (50+), all of which feature deeply-recursive DNS names. For the record, Wireshark routinely took an hour or more to load traces of 1M of these packets. Based on my understanding of the Bro code, it looks like parsing "normal" DNS traffic (real DNS scraped from my own web browsing) only accounts for 4-5% of all CPU time (I used Shark on OS X with a debug build, and checked the sampled CPU time of all descendants of UDP_Analyzer::DeliverPacket()). I'm using a version of the "detect backdoors" script which includes DPD, which might have skewed the results a little. (If anyone has comments on this, I'd appreciate hearing them). In either case, my bad DNS traffic only pushed the binpac-based analyzers up to 13-14% of CPU time, which is still comparatively tiny in relation to the EventMgr's CPU time. What I take away from this is that, even if binpac is slow, it's not the piece that most demands attention. So I started thinking about the systems-level issues (the Shunt paper took this same direction), and realized the main event loop is single-threaded. And that got me to where I am today :-) > >> I'm wondering what the ICSI folks' position is on threads vs. clustering. > > In short: we consider them orthogonal and are pursuing both. :-) > > To elaborate a bit: The cluster is the approach that can provide > significantly increased performance right now; ignoring a few > implementation glitches we still need to sort out, it's working and > ready to use[1]. The cluster is also an approach that will work > long-term: there will always be limits to what a single box can do > (multi-core or not) and the cluster offers the capability to go > beyond that. You're right about scale, modulo communications issues. However, I think it's important for a large-scale system to be designed in such a way as to gain more performance as the architecture guys throw faster and faster chips over the wall. The way I read the tea leaves, the number of CPU cores in commodity PCs isn't dropping anytime soon, so software that isn't written with multi- threaded event loops is going to hit a performance wall even as CPUs get faster. > > That said, we are in parallel (no pun intended :) working on a > multi-threaded Bro implementation. While we have already made quite > a bit of progress on that, that will however still take a bit to get > into any kind of usable state; we need to restructure Bro internally > quite a bit to exploit its concurrency potential. Once finished > though, we expect Bro's performance to scale pretty well with the > number of available cores (not considering other aspects of the > hardware which might turn into bottlenecks at some point). The > Sarnoff paper has some of the basic ideas for the multi-threaded > Bro, and there'll be an extended journal version of that coming out > soon with more details on the parallel execution model (let me know > if you'd to like to get a draft). > > Does that answer your question? If you have any particular thoughts > on either clustering or the multi-threaded Bro, I'd be happy to hear > them. I haven't explored how threadable Bro would be, but it seems you're already on it. Truthfully, I spent a few weeks picking through the code to convince myself I knew roughly how to profile it; I'm no expert on Bro internals. I'm going to have a chat with Nikita soon (my academic adviser) to see what he thinks about all this, and I'll be in touch. Please send the draft of the Sarnoff paper to my UIUC email address; I'd love to have a look. I'm wondering how you plan to address cache behavior in your multi-threaded implementation of Bro. Obviously, this is a really hard problem, and I'm not sure how well-studied it is in the literature, especially in the context of IDS. Fortunately, I have a lot of friends here that do high-performance computing work (their long-range research agenda includes a 3000-core CPU tapeout), so I'll talk to them about it. David _______________________________________________ Bro mailing list bro at bro-ids.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From jmellander at lbl.gov Mon Mar 2 12:12:17 2009 From: jmellander at lbl.gov (Jim Mellander) Date: Mon, 02 Mar 2009 12:12:17 -0800 Subject: [Bro] A more parallel Bro In-Reply-To: <0E07074B82CE4B4A9982802A8484B69672791584E7@EXCHANGE2K7.tacc.utexas.edu> References: <20090302102542.BYE93712@expms4.cites.uiuc.edu> <0E07074B82CE4B4A9982802A8484B69672791584E7@EXCHANGE2K7.tacc.utexas.edu> Message-ID: <49AC3DA1.5070505@lbl.gov> I'm running literally dozens of bros on a 8 core system, each listening to its own lightly loaded virtual interface. Its a fairly specialized internal monitoring application where lightweight probes send internal traffic to a centralized system which then pushes each probe's traffic onto its own virtual interface, which is then listened to by a bro. In the future, it may be that I implement a master bro that coordinates all the baby bro's - probably will wait for Robin to get the kinks out of the cluster code first. Hope this helps. William L. Jones wrote: > It is possible to take advantage of muti cpu system with the current bro. I am running 4 cpu test system now that runs 4 bro instances on 10GigE interface using a modification of the odd/even filter that was suggest on bro wiki in the User Manual: Performance Tuning section. > > It is spreading the load across the cpus. > > > Bill Jones > > > -----Original Message----- > From: bro-bounces at ICSI.Berkeley.EDU [mailto:bro-bounces at ICSI.Berkeley.EDU] On Behalf Of dalbrech at illinois.edu > Sent: Monday, March 02, 2009 10:26 AM > To: bro at ICSI.Berkeley.EDU > Subject: Re: [Bro] A more parallel Bro > > Robin Sommer wrote: >> On Wed, Feb 25, 2009 at 14:26 -0600, dalbrech at illinois.edu wrote: >> >>> I've been doing some performance profiling on Bro. >> Interesting! Do you have any results you could share? > I saw Vern's talk a while back at UIUC about how Bro works. As I recall, there > were three major components: > > 1. A packet capture engine, based on libpcap, which makes use of BPF to > selectively discard packets as early as practical (to reduce the overall quantity of > traffic), > 2. Protocol parsers, which turn blocks of data from the network into > semantically-meaningful PDU-like data structures, and > 3. An event engine, which applies constraints to the lexed protocol data, and > possibly raises alarms if the traffic is suspicious or otherwise "interesting". > > My group initially decided to pursue protocol parsing, because our micro- > benchmarks (many of which appeared in our RAID '08 paper) showed that > protocol parser-generators (e.g. binpac and Nikita et al.'s GAPA) leave > significant performance on the table versus a hand-coded parser. In particular, > binpac's use of C++ objects to represent PDUs really suffers on protocols > which feature small, deeply-nested messages, like DNS. > > However, the ultimate question is how much the performance gap between a > hand-coded parser vs. a machine-generated one matters in the context of a > real system. So I built a simple tool I call "dns-packet-gen", which generates > pathological DNS packets constructed for their difficulty in parsing. The tool > emits pcap traces containing DNS traffic with many records (50+), all of which > feature deeply-recursive DNS names. For the record, Wireshark routinely took > an hour or more to load traces of 1M of these packets. > > Based on my understanding of the Bro code, it looks like parsing "normal" DNS > traffic (real DNS scraped from my own web browsing) only accounts for 4-5% > of all CPU time (I used Shark on OS X with a debug build, and checked the > sampled CPU time of all descendants of UDP_Analyzer::DeliverPacket()). I'm > using a version of the "detect backdoors" script which includes DPD, which > might have skewed the results a little. (If anyone has comments on this, I'd > appreciate hearing them). In either case, my bad DNS traffic only pushed the > binpac-based analyzers up to 13-14% of CPU time, which is still comparatively > tiny in relation to the EventMgr's CPU time. > > What I take away from this is that, even if binpac is slow, it's not the piece that > most demands attention. So I started thinking about the systems-level issues > (the Shunt paper took this same direction), and realized the main event loop is > single-threaded. And that got me to where I am today :-) >>> I'm wondering what the ICSI folks' position is on threads vs. clustering. >> In short: we consider them orthogonal and are pursuing both. :-) >> >> To elaborate a bit: The cluster is the approach that can provide >> significantly increased performance right now; ignoring a few >> implementation glitches we still need to sort out, it's working and >> ready to use[1]. The cluster is also an approach that will work >> long-term: there will always be limits to what a single box can do >> (multi-core or not) and the cluster offers the capability to go >> beyond that. > You're right about scale, modulo communications issues. However, I think it's > important for a large-scale system to be designed in such a way as to gain > more performance as the architecture guys throw faster and faster chips over > the wall. The way I read the tea leaves, the number of CPU cores in commodity > PCs isn't dropping anytime soon, so software that isn't written with multi- > threaded event loops is going to hit a performance wall even as CPUs get > faster. >> That said, we are in parallel (no pun intended :) working on a >> multi-threaded Bro implementation. While we have already made quite >> a bit of progress on that, that will however still take a bit to get >> into any kind of usable state; we need to restructure Bro internally >> quite a bit to exploit its concurrency potential. Once finished >> though, we expect Bro's performance to scale pretty well with the >> number of available cores (not considering other aspects of the >> hardware which might turn into bottlenecks at some point). The >> Sarnoff paper has some of the basic ideas for the multi-threaded >> Bro, and there'll be an extended journal version of that coming out >> soon with more details on the parallel execution model (let me know >> if you'd to like to get a draft). >> >> Does that answer your question? If you have any particular thoughts >> on either clustering or the multi-threaded Bro, I'd be happy to hear >> them. > I haven't explored how threadable Bro would be, but it seems you're already on > it. Truthfully, I spent a few weeks picking through the code to convince myself > I knew roughly how to profile it; I'm no expert on Bro internals. I'm going to > have a chat with Nikita soon (my academic adviser) to see what he thinks about > all this, and I'll be in touch. Please send the draft of the Sarnoff paper to my > UIUC email address; I'd love to have a look. > > I'm wondering how you plan to address cache behavior in your multi-threaded > implementation of Bro. Obviously, this is a really hard problem, and I'm not > sure how well-studied it is in the literature, especially in the context of IDS. > Fortunately, I have a lot of friends here that do high-performance computing > work (their long-range research agenda includes a 3000-core CPU tapeout), so > I'll talk to them about it. > > David > _______________________________________________ > 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 > -- Jim Mellander Incident Response Manager Computer Protection Program Lawrence Berkeley National Laboratory (510) 486-7204 The reason you are having computer problems is: Groundskeepers stole the root password From lruppert at syr.edu Tue Mar 3 13:03:05 2009 From: lruppert at syr.edu (Lou Ruppert) Date: Tue, 03 Mar 2009 16:03:05 -0500 Subject: [Bro] analysis-groups Message-ID: <1236114185.7540.22.camel@aetheling.syr.edu> Hello. We're in the process of upgrading our IDS infrastructure here, and I've been trying for the last week or so to get the "release" version of bro up and running. It refuses and then it shames me. First, I'll detail what I've tried, and then I'll tell you where I'm stuck. I downloaded the "release" version of 1.4, thinking it would be a breeze to install like 1.3 was. I attempted to compile and install it, only to find out that the part that actually allows it to install and run (bro-lite) was not only deprecated, but was helpfully disabled as shipped in order to prevent me from blundering into an unsupportable situation. I read a huge chunk of the mailing list archives and determined that in order to use the "release" version of bro, I would have to install a bleeding-edge clustering component, as a test of my mettle. I followed the instructions at http://blog.ncsa.uiuc.edu/aashish/2008/10/21/moving-to-bro-14/ and compiled the clustering component, running it in standalone mode. When I try running the clustering component, it complains that it doesn't have the analysis-groups.bro component, which appears to be part of some changes made to the policy files but only made available to some inner cabal of bro developers. Not to be thwarted, I used Google to try to find out about the file, and found a hidden copy in the web interface of the SVN repository. Naively thinking this would solve my problem, I installed it in /usr/local/bro/current/policy/local/ and was finally able to get bro to start without instantly dying. That brings me to right now, where I'm stuck. Bro will run for a few minutes, generating the usual mass of data before suddenly deciding to segfault and die. As best I can tell, it's dying in DNS_Mgr::Process() . I'm guessing that's not normal behavior, or someone else would probably have emailed about it. Any ideas on how to get a working install of bro 1.4? Thanks for your help, and for writing it in the first place, -Lou (hoping for more to put on his 2008-2009 performance evaluation than "heroically spent FY08-09 compiling bro over and over again.") From robin at icir.org Tue Mar 3 14:40:25 2009 From: robin at icir.org (Robin Sommer) Date: Tue, 3 Mar 2009 14:40:25 -0800 Subject: [Bro] A more parallel Bro In-Reply-To: <20090302102542.BYE93712@expms4.cites.uiuc.edu> References: <20090302102542.BYE93712@expms4.cites.uiuc.edu> Message-ID: <20090303224025.GF46143@icir.org> On Mon, Mar 02, 2009 at 10:25 -0600, dalbrech at illinois.edu wrote: > real system. So I built a simple tool I call "dns-packet-gen", which generates > pathological DNS packets constructed for their difficulty in parsing. The tool > emits pcap traces containing DNS traffic with many records (50+), all of which > feature deeply-recursive DNS names. Neat. Is that tool available? > appreciate hearing them). In either case, my bad DNS traffic only pushed the > binpac-based analyzers up to 13-14% of CPU time, which is still comparatively > tiny in relation to the EventMgr's CPU time. Yeah. Some of our recent measurements indicate that for some protocols (including DNS) script interpretation dominitates the performance, with the analyzers being less of an issue. That's why our first target for the multi-threaded Bro is to parallelize script interpretation. > You're right about scale, modulo communications issues. However, I think it's > important for a large-scale system to be designed in such a way as to gain > more performance as the architecture guys throw faster and faster chips over > the wall. Definitely. As I said, we're interested in both, from a research perspective as well as for operations. > I'm wondering how you plan to address cache behavior in your multi-threaded > implementation of Bro. Obviously, this is a really hard problem, and I'm not > sure how well-studied it is in the literature, especially in the context of IDS. That's an excellent question and I don't think it has been studied in the IDS context yet. Our main strategy is to keep related state together, e.g., by running all analysis involving the same connection on the same core. It's hard to predict though how cache effects will eventually turn out to hurt us, and we expect to do a number of measurements in this regard once the multi-threaded Bro is in a shape that we can actually measure something. Going from there, I'm sure there'll be lots of further optimization potential. > Fortunately, I have a lot of friends here that do high-performance computing > work (their long-range research agenda includes a 3000-core CPU tapeout), so > I'll talk to them about it. I'd be glad to hear what they have to say as I'm not very familiar with this space myself either. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From robin at icir.org Tue Mar 3 14:47:59 2009 From: robin at icir.org (Robin Sommer) Date: Tue, 3 Mar 2009 14:47:59 -0800 Subject: [Bro] A more parallel Bro In-Reply-To: <0E07074B82CE4B4A9982802A8484B69672791584E7@EXCHANGE2K7.tacc.utexas.edu> References: <20090302102542.BYE93712@expms4.cites.uiuc.edu> <0E07074B82CE4B4A9982802A8484B69672791584E7@EXCHANGE2K7.tacc.utexas.edu> Message-ID: <20090303224759.GH46143@icir.org> On Mon, Mar 02, 2009 at 11:41 -0600, William L. Jones wrote: > It is possible to take advantage of muti cpu system with the current > bro. I am running 4 cpu test system now that runs 4 bro instances > on 10GigE interface using a modification of the odd/even filter that > was suggest on bro wiki in the User Manual: Performance Tuning > section. That's indeed a solution too, and in fact the cluster shell supports such a setup out of the box: if you configure it to install multiple backends on a single host, it will set things up accordingly (except for your custom BPF filter which one would still need to configure manually.). I don't have much experience with such a setup though. One thing I'd like to know is how the capture performance is when running multiple Bros. Is it a problem to have multiple, high-load packet capturing processes running at the same time, or is the kernel able to handle that just fine? Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From robin at icir.org Tue Mar 3 15:02:25 2009 From: robin at icir.org (Robin Sommer) Date: Tue, 3 Mar 2009 15:02:25 -0800 Subject: [Bro] analysis-groups In-Reply-To: <1236114185.7540.22.camel@aetheling.syr.edu> References: <1236114185.7540.22.camel@aetheling.syr.edu> Message-ID: <20090303230225.GJ46143@icir.org> On Tue, Mar 03, 2009 at 16:03 -0500, you wrote: > up and running. It refuses and then it shames me. First, I'll detail > what I've tried, and then I'll tell you where I'm stuck. I'm sorry about the trouble but you're actually mixing multiple things here. > I attempted to compile and install it, only to find out that the part > that actually allows it to install and run (bro-lite) was not only > deprecated, but was helpfully disabled as shipped in order to prevent me > from blundering into an unsupportable situation. The bro-lite install is indeed broken in 1.4 but there's a patch in our tracker which seems to fix the issue; see http://tracker.icir.org/bro/ticket/51 . Please try this and let me know if it works for you. > I read a huge chunk of the mailing list archives and determined that in > order to use the "release" version of bro, I would have to install a > bleeding-edge clustering component, as a test of my mettle. The cluster shell scripts are supposed to be used only with my development branch for now. Using them with 1.4 may or may not work, I don't know. > Not to be thwarted, I used Google to try to find out about the file, and > found a hidden copy in the web interface of the SVN repository. Well, it's not exactly hidden. If you'd checked out the development branch (see above), you would have had it. > segfault and die. As best I can tell, it's dying in > DNS_Mgr::Process() . I'm guessing that's not normal behavior, or > someone else would probably have emailed about it. Hard to tell what this is without further information. There's a blog posting at http://blog.icir.org/2009/01/how-to-report-bro-problem.html describing how to get more context for such problems. In particular, a stack backtrace would be helpful here. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From robin at icir.org Tue Mar 3 15:02:25 2009 From: robin at icir.org (Robin Sommer) Date: Tue, 3 Mar 2009 15:02:25 -0800 Subject: [Bro] analysis-groups In-Reply-To: <1236114185.7540.22.camel@aetheling.syr.edu> References: <1236114185.7540.22.camel@aetheling.syr.edu> Message-ID: <20090303230225.GJ46143@icir.org> On Tue, Mar 03, 2009 at 16:03 -0500, you wrote: > up and running. It refuses and then it shames me. First, I'll detail > what I've tried, and then I'll tell you where I'm stuck. I'm sorry about the trouble but you're actually mixing multiple things here. > I attempted to compile and install it, only to find out that the part > that actually allows it to install and run (bro-lite) was not only > deprecated, but was helpfully disabled as shipped in order to prevent me > from blundering into an unsupportable situation. The bro-lite install is indeed broken in 1.4 but there's a patch in our tracker which seems to fix the issue; see http://tracker.icir.org/bro/ticket/51 . Please try this and let me know if it works for you. > I read a huge chunk of the mailing list archives and determined that in > order to use the "release" version of bro, I would have to install a > bleeding-edge clustering component, as a test of my mettle. The cluster shell scripts are supposed to be used only with my development branch for now. Using them with 1.4 may or may not work, I don't know. > Not to be thwarted, I used Google to try to find out about the file, and > found a hidden copy in the web interface of the SVN repository. Well, it's not exactly hidden. If you'd checked out the development branch (see above), you would have had it. > segfault and die. As best I can tell, it's dying in > DNS_Mgr::Process() . I'm guessing that's not normal behavior, or > someone else would probably have emailed about it. Hard to tell what this is without further information. There's a blog posting at http://blog.icir.org/2009/01/how-to-report-bro-problem.html describing how to get more context for such problems. In particular, a stack backtrace would be helpful here. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From dalbrech at illinois.edu Wed Mar 4 08:33:07 2009 From: dalbrech at illinois.edu (dalbrech at illinois.edu) Date: Wed, 4 Mar 2009 10:33:07 -0600 (CST) Subject: [Bro] A more parallel Bro Message-ID: <20090304103307.BYI63329@expms4.cites.uiuc.edu> Robin Sommer wrote: > On Mon, Mar 02, 2009 at 10:25 -0600, dalbrech at illinois.edu wrote: > >> real system. So I built a simple tool I call "dns-packet-gen", which generates >> pathological DNS packets constructed for their difficulty in parsing. The tool >> emits pcap traces containing DNS traffic with many records (50+), all of which >> feature deeply-recursive DNS names. > > Neat. Is that tool available? Making it available is on my todo, but it's toward the bottom. My group currently doesn't have a good web presence, but we're planning to fix that one of these days as I think it does a lot for a research group's visibility. >> I'm wondering how you plan to address cache behavior in your multi- threaded >> implementation of Bro. Obviously, this is a really hard problem, and I'm not >> sure how well-studied it is in the literature, especially in the context of IDS. > > That's an excellent question and I don't think it has been studied > in the IDS context yet. Our main strategy is to keep related state > together, e.g., by running all analysis involving the same > connection on the same core. It's hard to predict though how cache > effects will eventually turn out to hurt us, and we expect to do a > number of measurements in this regard once the multi-threaded Bro is > in a shape that we can actually measure something. Going from there, > I'm sure there'll be lots of further optimization potential. I'm going to start analyzing Bro's memory use and performance; do you have any recommendations about which policy I use? I'm looking for a reasonably "representative" workload (if such a thing even exists), something that will test a lot of code paths through the system. Thanks again, DA -- David R. Albrecht Graduate Assistant, Hatswitch Group U. Illinois Urbana-Champaign (312) 445-0883 From robin at icir.org Thu Mar 5 13:38:21 2009 From: robin at icir.org (Robin Sommer) Date: Thu, 5 Mar 2009 13:38:21 -0800 Subject: [Bro] A more parallel Bro In-Reply-To: <20090304103307.BYI63329@expms4.cites.uiuc.edu> References: <20090304103307.BYI63329@expms4.cites.uiuc.edu> Message-ID: <20090305213821.GI47023@icir.org> On Wed, Mar 04, 2009 at 10:33 -0600, you wrote: > I'm going to start analyzing Bro's memory use and performance; do you have > any recommendations about which policy I use? Here's a sequence of scripts imposing increasing load on Bro that we have been using in the past for some of our measurements: (1) tcp (2) tcp mt (3) tcp mt scan trw (4) tcp mt scan trw udp icmp (5) tcp mt scan trw udp icmp http-request http-reply http-body http-header (6) tcp mt scan trw udp icmp http-request http-reply http-body http-header ssh pop3 irc ssl smtp It's also worth comparing running with the connection compressor vs. without (use_connection_compressor=T/F). And keep an eye on the packet filter; it's easy to forget but can have quite an impact on performance depending on what it lets through and what not. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From inasiriyah at yahoo.com Fri Mar 6 05:08:16 2009 From: inasiriyah at yahoo.com (Nasiriyah Iraq) Date: Fri, 6 Mar 2009 05:08:16 -0800 (PST) Subject: [Bro] Monitor the traffic form interface and pass it to other interface Message-ID: <147604.88111.qm@web59710.mail.ac4.yahoo.com> Dear all I have server with Ubuntu 8.10 operating system and Bro Ids 1.4, and there are two network interfaces installed in this server eth0 and eth1. The interface eth0 connected to the internet, and the interface eth1 connected to my special local area network. How can I make Bro IDS monitor and analyze all the traffic come from eth0? And after that pass the traffic to eth1? ? Regards, Kaled Hussain M.Sc. IT Student UUM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20090306/2449072d/attachment.html From vern at icir.org Fri Mar 6 12:50:45 2009 From: vern at icir.org (Vern Paxson) Date: Fri, 06 Mar 2009 12:50:45 -0800 Subject: [Bro] Monitor the traffic form interface and pass it to other interface In-Reply-To: <147604.88111.qm@web59710.mail.ac4.yahoo.com> (Fri, 06 Mar 2009 05:08:16 PST). Message-ID: <200903062050.n26Kookm027597@pork.ICSI.Berkeley.EDU> > How can I make Bro IDS monitor and analyze all the traffic come from eth0? Use redef interfaces = "eth0"; in you policy script, or "bro -i eth0 ..." when you execute Bro. > And after that pass the traffic to eth1? Bro doesn't have a packet forwarding capability for inline operation. Vern From jean-philippe.luiggi at didconcept.com Sat Mar 7 12:02:37 2009 From: jean-philippe.luiggi at didconcept.com (jean-philippe luiggi) Date: Sat, 7 Mar 2009 15:02:37 -0500 Subject: [Bro] Monitor the traffic form interface and pass it to other interface In-Reply-To: <147604.88111.qm@web59710.mail.ac4.yahoo.com> References: <147604.88111.qm@web59710.mail.ac4.yahoo.com> Message-ID: <20090307200237.GA19704@192.168.2.103> Hello, I'm not (yet) sure of what's your exact setup but Bro acts as a "viewer" and is unable to inject data. Now about your need, if you want to get packets on eth0 and just forward them to eth1, you may use firewall's rules. With regards, Jean-Philippe. * Nasiriyah Iraq [2009-03-06 05:08:16 -0800]: > Dear all > I have server with Ubuntu 8.10 operating system and Bro Ids 1.4, and there are two network interfaces installed in this server eth0 and eth1. > The interface eth0 connected to the internet, and the interface eth1 connected to my special local area network. > How can I make Bro IDS monitor and analyze all the traffic come from eth0? And after that pass the traffic to eth1? ? From jean-philippe.luiggi at didconcept.com Sat Mar 7 14:15:29 2009 From: jean-philippe.luiggi at didconcept.com (jean-philippe luiggi) Date: Sat, 7 Mar 2009 17:15:29 -0500 Subject: [Bro] Data Visualization Message-ID: <20090307221529.GB19704@192.168.2.103> Hello Everybody, I did a (simple) perl script in order to use Bro with "Picviz", this tool is a parallel coordinates plotter which helps to visualize your data using parallel coordinates plots (http://en.wikipedia.org/wiki/Parallel_coordinates). Here are the parameters i plot : time, src_ip, src_port, src_bytes, dst_ip, dst_port, receive_bytes, duration, state. The states are the same Bro is reporting about : "S0,S1,SF,REJ,S2,S3,RSTO,RSTR,RSTOS0,RSTRH,SH,SHR,OTH", I plot them using 3 groups of colors : "S0,S1,S2,S3, REJ,RSTO,RSTR" as "blue" "SF" as "green" "RSTOS0,RSTRH,SH,SHR,OTH" as "red" } Using parallel coordinates plots is a very useful way to see what's happening so happy "Picvizing" :-) You'll find the files i use at http://www.rootshell.be/~jpli/picviz and "Picviz" is available at http://www.wallinfire.net/picviz With regards, Jean-Philippe. From inasiriyah at yahoo.com Tue Mar 17 08:44:45 2009 From: inasiriyah at yahoo.com (Nasiriyah Iraq) Date: Tue, 17 Mar 2009 08:44:45 -0700 (PDT) Subject: [Bro] The pre-processors in Snort and the corresponding in Bro IDS Message-ID: <313317.79002.qm@web59702.mail.ac4.yahoo.com> Dear all Thank for the answers for the my last post. ? There are many pre-processors available in Snort like: Flow sfPortscan Stream4 Frag2 Telenet_negotiation Http_inspect ? My?question is what are the corresponding for these pre-processors in Bro IDS? And how can I make every one on or off? Thanks for all ? ? regards Kaled? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20090317/64df515d/attachment.html From sychan at lbl.gov Thu Mar 19 11:33:25 2009 From: sychan at lbl.gov (Stephen Chan) Date: Thu, 19 Mar 2009 11:33:25 -0700 Subject: [Bro] Patch to bropipe.cc Message-ID: <49C28FF5.6040007@lbl.gov> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, I was doing some testing on bropipe for our migration to 1.4, and came across a bug that resulted segfaults on malformed input. I've patched it and am including it. There's some random formatting changes that you can delete from the diff if you like - the important changes are around line 463. There's some changes around line 530 that look like they are legit, but don't seem to be in the trunk, it seems like they somehow escaped submission earlier. The patch is an svn diff, let me know if I should submit it differently. Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknCj/UACgkQcVd2YI1BWAjGZACggkPbsKKrav9IEiobH6UOXn2t PDYAoJCU8b6vBR1yiUage8rP5zdYugsp =BSV/ -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bropipe.patch Url: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20090319/d6f6253b/attachment.ksh From robin at icir.org Fri Mar 20 13:53:57 2009 From: robin at icir.org (Robin Sommer) Date: Fri, 20 Mar 2009 13:53:57 -0700 Subject: [Bro] Patch to bropipe.cc In-Reply-To: <49C28FF5.6040007@lbl.gov> References: <49C28FF5.6040007@lbl.gov> Message-ID: <20090320205357.GC45819@icir.org> On Thu, Mar 19, 2009 at 11:33 -0700, you wrote: > The patch is an svn diff, let me know if I should submit it > differently. Thanks for the patch. Best is to submit to the tracker, then it won't get lost. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From robin at icir.org Fri Mar 20 13:53:57 2009 From: robin at icir.org (Robin Sommer) Date: Fri, 20 Mar 2009 13:53:57 -0700 Subject: [Bro] Patch to bropipe.cc In-Reply-To: <49C28FF5.6040007@lbl.gov> References: <49C28FF5.6040007@lbl.gov> Message-ID: <20090320205357.GC45819@icir.org> On Thu, Mar 19, 2009 at 11:33 -0700, you wrote: > The patch is an svn diff, let me know if I should submit it > differently. Thanks for the patch. Best is to submit to the tracker, then it won't get lost. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From nikhil.m.agrawal at gmail.com Sun Mar 22 08:55:41 2009 From: nikhil.m.agrawal at gmail.com (Nikhil Agrawal) Date: Sun, 22 Mar 2009 21:25:41 +0530 Subject: [Bro] Info of KaZaA Message-ID: Respected sir, i want some information on how KaZaA works.its detail information and working -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20090322/f31f6f32/attachment.html From bob.debolt at starblanket.ca Sun Mar 22 14:06:32 2009 From: bob.debolt at starblanket.ca (bob.debolt at starblanket.ca) Date: Sun, 22 Mar 2009 15:06:32 -0600 Subject: [Bro] Info of KaZaA In-Reply-To: References: Message-ID: <000801c9ab32$140c6180$3c252480$@debolt@starblanket.ca> Best suggestion in my view is to use something like wireshark to study some traffic captures. Ask questions based on acquired info. From: bro-bounces at ICSI.Berkeley.EDU [mailto:bro-bounces at ICSI.Berkeley.EDU] On Behalf Of Nikhil Agrawal Sent: Sunday, March 22, 2009 9:56 AM To: Bro at ICSI.Berkeley.EDU Subject: [Bro] Info of KaZaA Respected sir, i want some information on how KaZaA works.its detail information and working -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20090322/09a76d10/attachment.html From christian at whoop.org Wed Mar 25 03:26:49 2009 From: christian at whoop.org (Christian Kreibich) Date: Wed, 25 Mar 2009 11:26:49 +0100 Subject: [Bro] Patch to bropipe.cc In-Reply-To: <20090320205357.GC45819@icir.org> References: <49C28FF5.6040007@lbl.gov> <20090320205357.GC45819@icir.org> Message-ID: <1237976809.28080.1.camel@localhost.localdomain> I've applied the patch in SVN trunk. Thanks Steve, and sorry for the delay. -- Cheers, Christian From inasiriyah at yahoo.com Wed Mar 25 10:58:27 2009 From: inasiriyah at yahoo.com (Nasiriyah Iraq) Date: Wed, 25 Mar 2009 10:58:27 -0700 (PDT) Subject: [Bro] Monitor the traffic form interface and pass it to other interface In-Reply-To: <20090307200237.GA19704@192.168.2.103> Message-ID: <630202.12403.qm@web59713.mail.ac4.yahoo.com> Hello ? Thank you for replay Actualy I want to use Bro as Intrusion Prevention System, and I? want to know which processors or options which affect the delay time? ? With regards ? Kaled Azrane ? --- On Sat, 3/7/09, jean-philippe luiggi wrote: From: jean-philippe luiggi Subject: Re: [Bro] Monitor the traffic form interface and pass it to other interface To: "Nasiriyah Iraq" Cc: bro at ICSI.Berkeley.EDU Date: Saturday, March 7, 2009, 8:02 PM Hello, I'm not (yet) sure of what's your exact setup but Bro acts as a "viewer" and is unable to inject data. Now about your need, if you want to get packets on eth0 and just forward them to eth1, you may use firewall's rules. With regards, Jean-Philippe. * Nasiriyah Iraq [2009-03-06 05:08:16 -0800]: > Dear all > I have server with Ubuntu 8.10 operating system and Bro Ids 1.4, and there are two network interfaces installed in this server eth0 and eth1. > The interface eth0 connected to the internet, and the interface eth1 connected to my special local area network. > How can I make Bro IDS monitor and analyze all the traffic come from eth0? And after that pass the traffic to eth1? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20090325/a0022ec8/attachment.html