From kjk at eecs.berkeley.edu Fri May 2 09:30:35 2008 From: kjk at eecs.berkeley.edu (Jayanth Kannan) Date: Fri, 2 May 2008 09:30:35 -0700 Subject: [Bro] help regarding sending scripts Message-ID: <5ea2307f0805020930u4b4519bfm8b8a94d0ff57e41c@mail.gmail.com> Hi, I have a question about sending scripts from one Bro to a second one, and having the second one install the script at run-time, and I was wondering how it would be done. Any help appreciated! Details below. I am running Bro at the host which needs to receive new policy scripts on the fly from a remote Bro. I was wondering how exactly to use the serialization framework to achieve this. Ideally, I would like to do it at the script-level for simplicity reasons. A script at the host Bro would handle the reception and installation of policy files. It would simply download the file from the remote Bro, and then call a function called "load_policy_file()" to install the script into the running Bro. I could not find any such function to do this in the online documentation. (equivalent of a run-time "@load"). Maybe, I missed something? If such support is not avail, I was thinking of writing a "load_policy_file" function for Bro that scripts could use. I was also wondering whether I could use the "trigger" mechanism discussed in the "Policy-controlled event management ... " paper, but the serialization framework seems heavy-weight for this, since I am only looking to install scripts at run-time, not to make fine-grained changes. Thanks in advance, Jayanth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20080502/e952b024/attachment.html From jhnovak at gmail.com Mon May 12 06:47:19 2008 From: jhnovak at gmail.com (Jesse Bortercollet) Date: Mon, 12 May 2008 09:47:19 -0400 Subject: [Bro] New Bro User Message-ID: <648c2ff20805120647o3fe6ca52n259c60bb7cc2ae17@mail.gmail.com> Hi, I'm trying to become familiar with Bro and have installed the stable release 1.2.1 on an Ubuntu VMware image running a 2.6 kernel. I have been following the documentation and wanted to see if I have everything installed properly by first reading a pcap to generate an alarm. I was looking at the reference manual, specifically Chapter 2: Getting Started 2.1.4.2 Traffic traces. I wanted to emulate the: bro -r example.ftp-attack.trace brolite where I was supposed to see a connection summary in stdout and some kind of alarm. I didn't find that particular pcap with the installation as the documentation says, but used a pcap from an earlier bro package - ftp-site-exec.trace. I ran the bro above command using this pcap, but I don't see any output at all. I'm familiar with Snort so I've used an IDS before. I just can't figure out what I might be doing wrong. Can someone please help? Thanks a lot - Jesse -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20080512/4625d435/attachment.html From robin at icir.org Wed May 14 17:30:11 2008 From: robin at icir.org (Robin Sommer) Date: Wed, 14 May 2008 17:30:11 -0700 Subject: [Bro] help regarding sending scripts In-Reply-To: <5ea2307f0805020930u4b4519bfm8b8a94d0ff57e41c@mail.gmail.com> References: <5ea2307f0805020930u4b4519bfm8b8a94d0ff57e41c@mail.gmail.com> Message-ID: <20080515003011.GZ93186@icir.org> (Late reply, sorry.) On Fri, May 02, 2008 at 09:30 -0700, you wrote: > I have a question about sending scripts from one Bro to a second one, and > having the second one install the script at run-time, and I was wondering > how it would be done. Any help appreciated! Details below. This requires a longer answer ... We don't have any prepackaged functionality at the moment to simply do a "send everything and install". What we have are two things: (a) a built-in function send_id() which will send a particular script-level ID to the remote end, which will install it. That includes variables but also event handlers, script functions, etc. By sending all global IDs successively, one will eventually have sent the whole configuration. (However, that would be best done in C++ code by writing a new built-in function). (b) If it doesn't need to be network communication, there's the command-line option "--dump-config" that puts the whole configuration into a binary file, which can then be picked up by another instance dynamically (by copying the file into the .state directory of the target Bro). Internally, dump-config essentially does just what I sketched above in (a): iterating through all IDs and serializing them. So much for the theory. Now the practical part: I think this whole set of functionality hasn't been used by anybody in a long time. Because of Bro's internal structure, replacing policy scripts at run-time is actually pretty tricky and I wouldn't want to bet much money that when you try --dump-config, it will "just work". It did seem to work well with tests done while implementing all this stuff, yet I think it has never been exercised very much and the problems are subtle here. So, depending on what exactly you need, I'd suggest something different, which is what the Bro cluster is doing: (1) many policy changes are limited to fine-tuning, e.g., changing the value of some configuration paramemter, like extending a regexp to match more activity, or changing some detection threshold. Sending just values of script variables works actually pretty well and the Bro cluster limits online updates to such cases: all variables which are declared as &redef can be updated dynamically from remote. This is implemented by the script aux/cluster/policy/send-config.bro in my branch. (2) another typical policy change is enabling/disabling a certain kind of analysis (such as now loading the HTTP analyzer, or disabling scan detection). My branch has some code to enable this from remote by grouping related events into "event groups" and then allowing to enable/disable event groups remotely. So this can also be done during run-time. (3) finally, for everyting else (like adding new script code, or changing an existing handler) Bro needs to be reinstarted. The impact of that is mitigated by using persistent state so that at least the most important state information is kept across restarts. Any questions? :-) Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From philou at philou.ch Thu May 15 05:13:15 2008 From: philou at philou.ch (Philippe Strauss) Date: Thu, 15 May 2008 14:13:15 +0200 Subject: [Bro] signatures: pros/cons, future plans for bro Message-ID: <20080515121315.GA21407@philou.ch> Hello Bro users, I'm currently reviewing opensource IDS for usage at an ISP. I really like bro clean and well thought design and implementation (C++ source code is really clean, especially when compared to snort C's which looks messy, TCP stream reconstruction was there way before snort, it's implemented in 5 times less kB of source code than snort etc...) But the needs of an IDS at an ISP may be a bit different than at an EDU/R&D site like Bro seems to have been designed for. Having a signature matcher is a must at an ISP: having a set of signature matching against the latest PHP whatever apps vulnerability in front of a hosting room for example. Bro does support it, but rather badly: there's a really good, custom built stream based regexp matcher, but the set of signature is the one of snort, using a pair or perl/python script to convert it. Conversion, between two different semantic pattern matcher leads to errors: in the snort2bro generated file, you'll see a lot of # Not supported line about string position or regexp syntax. My question is: is there plan to have a better support of bro signature, by improving snort2bro and/or modifiying the bro pattern matcher to be closer than snort one? Is there needs in the bro users community that match the ones I describe? Also, I've read somewhere of futures plan to have netflow support, what is the plan (the idea is very good: coarse grained unsual flow detection using netflow, the refined analysis thru bro) Regards. -- Philippe Strauss av. de Beaulieu 25 1004 Lausanne http://philou.ch From kjk at eecs.berkeley.edu Thu May 15 09:45:16 2008 From: kjk at eecs.berkeley.edu (Jayanth Kannan) Date: Thu, 15 May 2008 09:45:16 -0700 Subject: [Bro] help regarding sending scripts In-Reply-To: <20080515003011.GZ93186@icir.org> References: <5ea2307f0805020930u4b4519bfm8b8a94d0ff57e41c@mail.gmail.com> <20080515003011.GZ93186@icir.org> Message-ID: <5ea2307f0805150945v26578cbhadeee1394bbba7b@mail.gmail.com> Thanks so much for the long and detailed reply! I am not quite sure which of the many options you suggested I would go for, but I will keep the list posted on what I end up doing. I guess I will play with all your options a little bit, and figure out what works for me. Thanks, Jayanth On Wed, May 14, 2008 at 5:30 PM, Robin Sommer wrote: > (Late reply, sorry.) > > On Fri, May 02, 2008 at 09:30 -0700, you wrote: > > > I have a question about sending scripts from one Bro to a second one, and > > having the second one install the script at run-time, and I was wondering > > how it would be done. Any help appreciated! Details below. > > This requires a longer answer ... > > We don't have any prepackaged functionality at the moment to simply > do a "send everything and install". > > What we have are two things: > > (a) a built-in function send_id() which will send a particular > script-level ID to the remote end, which will install it. That > includes variables but also event handlers, script functions, > etc. By sending all global IDs successively, one will eventually > have sent the whole configuration. (However, that would be best > done in C++ code by writing a new built-in function). > > (b) If it doesn't need to be network communication, there's the > command-line option "--dump-config" that puts the whole > configuration into a binary file, which can then be picked up by > another instance dynamically (by copying the file into the > .state directory of the target Bro). Internally, dump-config > essentially does just what I sketched above in (a): iterating > through all IDs and serializing them. > > So much for the theory. Now the practical part: I think this whole > set of functionality hasn't been used by anybody in a long time. > Because of Bro's internal structure, replacing policy scripts at > run-time is actually pretty tricky and I wouldn't want to bet much > money that when you try --dump-config, it will "just work". It did > seem to work well with tests done while implementing all this stuff, > yet I think it has never been exercised very much and the problems > are subtle here. > > So, depending on what exactly you need, I'd suggest something > different, which is what the Bro cluster is doing: > > (1) many policy changes are limited to fine-tuning, e.g., changing > the value of some configuration paramemter, like extending a > regexp to match more activity, or changing some detection > threshold. Sending just values of script variables works > actually pretty well and the Bro cluster limits online updates > to such cases: all variables which are declared as &redef can be > updated dynamically from remote. This is implemented by the > script aux/cluster/policy/send-config.bro in my branch. > > (2) another typical policy change is enabling/disabling a certain > kind of analysis (such as now loading the HTTP analyzer, or > disabling scan detection). My branch has some code to enable > this from remote by grouping related events into "event groups" > and then allowing to enable/disable event groups remotely. So > this can also be done during run-time. > > (3) finally, for everyting else (like adding new script code, or > changing an existing handler) Bro needs to be reinstarted. The > impact of that is mitigated by using persistent state so > that at least the most important state information is kept > across restarts. > > > Any questions? :-) > > Robin > > > -- > Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org > ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20080515/7c745c4d/attachment.html From robin at icir.org Thu May 15 11:11:27 2008 From: robin at icir.org (Robin Sommer) Date: Thu, 15 May 2008 11:11:27 -0700 Subject: [Bro] signatures: pros/cons, future plans for bro In-Reply-To: <20080515121315.GA21407@philou.ch> References: <20080515121315.GA21407@philou.ch> Message-ID: <20080515181127.GD4822@icir.org> Hi Philippe, great yo hear you guys are considering Bro. On Thu, May 15, 2008 at 14:13 +0200, Philippe Strauss wrote: > Conversion, between two different semantic pattern matcher leads to > errors: in the snort2bro generated file, you'll see a lot of > # Not supported > line about string position or regexp syntax. You're absolutely right. I don't recommend using snort2bro anymore, it's outdated and doesn't support many of Snort's new options. > My question is: is there plan to have a better support of bro signature, > by improving snort2bro and/or modifiying the bro pattern matcher to be > closer than snort one? No, not on our side, we don't maintain it anymore. For our setups, we have decided that converting Snort rules is not really worth the trouble; we don't get enough benefit out of them. (YMMV.) > Is there needs in the bro users community that match the ones I > describe? A few folks have expressed interest in the past in bringing snort2bro back to live. If somebody were to take over snort2bro development, I'm sure the Bro community would appreciate that. (I actually once started to build a better snort-regexp-to-bro-regexp converter but I'm afraid I lost the code; can't find it anymore :-( ) > Also, I've read somewhere of futures plan to have netflow support, what > is the plan (the idea is very good: coarse grained unsual flow detection > using netflow, the refined analysis thru bro) There's experimental NetFlow support, written by Bernhard Ager, in my working branch. I plan to write a few words about how to use it on the ICSI blog sometime soon. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From llovo at 163.com Thu May 15 21:55:49 2008 From: llovo at 163.com (LuLei) Date: Fri, 16 May 2008 12:55:49 +0800 (CST) Subject: [Bro] Ask for Bro Cluster source code Message-ID: <29952860.1244871210913749526.JavaMail.coremail@bj163app110.163.com> Dear Bro developers: I am a college student in China, I am studying network technology. I am interested in Bro and IDS Cluster, and I have read the RAID Paper, had a brief understanding of the general architecture. For further study, I want to know more detail about the Cluster, especially how to use Click modular router in implementation of the cluster on Linux. May I get the source code of cluster if it is possible, and how? Looking forward to hearing from you. Best wishes, Leo May 14, 2008 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20080516/f72ecf41/attachment.html From kevlo at kevlo.org Thu May 15 22:12:24 2008 From: kevlo at kevlo.org (Kevin Lo) Date: Fri, 16 May 2008 13:12:24 +0800 Subject: [Bro] Ask for Bro Cluster source code In-Reply-To: <29952860.1244871210913749526.JavaMail.coremail@bj163app110.163.com> References: <29952860.1244871210913749526.JavaMail.coremail@bj163app110.163.com> Message-ID: <1210914744.7032.29.camel@nsl> LuLei wrote: > Dear Bro developers: > I am a college student in China, I am studying network technology. > I am interested in Bro and IDS Cluster, and I have read the RAID > Paper, had a brief understanding of the general architecture. For > further study, I want to know more detail about the Cluster, > especially how to use Click modular router in implementation of the > cluster on Linux. May I get the source code of cluster if it is > possible, and how? Check out the cluster source code of Robin's SVN branch: http://svn.icir.org/bro/branches/robin/work/aux/cluster/ > Looking forward to hearing from you. > Best wishes, > > Leo > May 14, > 2008 Kevin From robin at icir.org Fri May 16 18:14:38 2008 From: robin at icir.org (Robin Sommer) Date: Fri, 16 May 2008 18:14:38 -0700 Subject: [Bro] Ask for Bro Cluster source code In-Reply-To: <1210914744.7032.29.camel@nsl> References: <29952860.1244871210913749526.JavaMail.coremail@bj163app110.163.com> <1210914744.7032.29.camel@nsl> Message-ID: <20080517011438.GB60942@icir.org> On Fri, May 16, 2008 at 13:12 +0800, Kevin Lo wrote: > http://svn.icir.org/bro/branches/robin/work/aux/cluster/ Note that the Click code is not in there at the moment. But I'll add it soon. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From rmkml at free.fr Sun May 18 17:29:38 2008 From: rmkml at free.fr (rmkml) Date: Mon, 19 May 2008 02:29:38 +0200 (CEST) Subject: [Bro] How to use HTTP ZIP detection/conversion ? Message-ID: Hi Bro Workers, Anyone how to extract zip on http stream and search (ids) on ? example with this link with firefox browser: http://www.milw0rm.com/exploits/5619 ... User-Agent: Mozilla/5.0 ..... ... Server: Apache Content-Encoding: gzip Vary: Accept-Encoding ... same with wget: ... User-Agent: Wget... ... Server: Apache ... example bro ids signature (snort like) work without encoding : signature sid-92912 { ip-proto == tcp event "example IE Print Table of Links" tcp-state established,responder http-body /.*[hH][rR][eE][fF]\s*=(.){0,16}[hH][tT][tT][pP]\:(.){0,49}=[^>]*<\s*([jJ][aA][vV][aA])?[sS][cC][rR][iI][pP][tT]/ } It is possible ? Regards Rmkml Crusoe-Researches.com From robin at icir.org Mon May 19 21:13:22 2008 From: robin at icir.org (Robin Sommer) Date: Mon, 19 May 2008 21:13:22 -0700 Subject: [Bro] How to use HTTP ZIP detection/conversion ? In-Reply-To: References: Message-ID: <20080520041322.GB64379@icir.org> On Mon, May 19, 2008 at 02:29 +0200, you wrote: > Anyone how to extract zip on http stream and search (ids) on ? Don't worry, It Just Works(TM) :-) Just make sure that configure can find zlib (w/ development headers). If unsure, double-check that HAVE_LIBZ is 1 in config.h. Then Bro will decode gzip content encodings and pass the unzipped data on to http-body's pattern matching. (If this doesn't seem to work for you even though configure found zlib, please send me a small trace and a signature which reproduce the problem.) Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From rmkml at free.fr Thu May 22 15:14:22 2008 From: rmkml at free.fr (rmkml) Date: Fri, 23 May 2008 00:14:22 +0200 (CEST) Subject: [Bro] Bro ids SSLv3 tls extension client hello patch Message-ID: Hi, first: big thank for all contributors on this great project ! second, I have added very little patch (alpha and incomplete) on bro v1.3.28_devel for removing alert when firefox browser connect on tls (https) server with tls extension. http://www.Crusoe-Researches.com/bro1328ssltlsextension_clienthello.diff.gz remains: server side hello extension, check in extension types ... for complete information on tls extension (Jan 2006): ftp://ftp.rfc-editor.org/in-notes/rfc4366.txt Regards Rmkml Crusoe-Researches.com From sullivan at cs.ucsb.edu Fri May 23 17:10:24 2008 From: sullivan at cs.ucsb.edu (Lorenzo Cavallaro) Date: Fri, 23 May 2008 17:10:24 -0700 Subject: [Bro] str_split Message-ID: <20080524001024.GA11673@galilei.laser.dico.unimi.it> Hi, I'd like to convert a string into an array of char (or a vector) so that it's possible to iterate over it (via the for stmt). Any idea about how to do it? I'm not sure if str_split is the right function but if so, I'm not sure what to use as index_vec argument. Iterate by using a set it'd be enough if I could generate the range of indexes belonging to the string... TIA, bye Lorenzo -- Lorenzo `Gigi Sullivan' Cavallaro GPG key at http://security.dico.unimi.it/~sullivan/sullivan.asc Until I loved, life had no beauty; I did not know I lived until I had loved. (Theodor Korner) See the reality in your eyes, when the hate makes you blind. (A.H.X) From robin at icir.org Sat May 24 06:58:04 2008 From: robin at icir.org (Robin Sommer) Date: Sat, 24 May 2008 06:58:04 -0700 Subject: [Bro] Bro ids SSLv3 tls extension client hello patch In-Reply-To: References: Message-ID: <20080524135804.GE6302@icir.org> On Fri, May 23, 2008 at 00:14 +0200, you wrote: > second, I have added very little patch (alpha and incomplete) on bro Thanks! I'll take a look at this together with some other patches I got for SSL. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From christian at whoop.org Wed May 28 16:29:57 2008 From: christian at whoop.org (Christian Kreibich) Date: Wed, 28 May 2008 16:29:57 -0700 Subject: [Bro] str_split In-Reply-To: <20080524001024.GA11673@galilei.laser.dico.unimi.it> References: <20080524001024.GA11673@galilei.laser.dico.unimi.it> Message-ID: <1212017397.30465.41.camel@strangepork> Lorenzo and I have been emailing off-list prior to his posting. I believe what Lorenzo wants to do is match a regular expression against flow content and obtain the matching part (or parts?) of the flow. For example, if the regex is [0-9]{5}, he'd like to obtain the 5-digit numerical string(s) that is/are present in the flow. My understanding is that the signature_match() event does not guarantee that all match-relevant data are actually passed to the event, so what is the best option? Manual buffer management and regex matching via {udp,tcp}_contents? On Fri, 2008-05-23 at 17:10 -0700, Lorenzo Cavallaro wrote: > Hi, > > I'd like to convert a string into an array of char (or a vector) so > that it's possible to iterate over it (via the for stmt). Any idea > about how to do it? > > I'm not sure if str_split is the right function but if so, I'm not > sure what to use as index_vec argument. Iterate by using a set it'd > be enough if I could generate the range of indexes belonging to the > string... > > TIA, bye > Lorenzo -- Cheers, Christian From vern at icir.org Wed May 28 22:23:45 2008 From: vern at icir.org (Vern Paxson) Date: Wed, 28 May 2008 22:23:45 -0700 Subject: [Bro] str_split In-Reply-To: <20080524001024.GA11673@galilei.laser.dico.unimi.it> (Fri, 23 May 2008 17:10:24 PDT). Message-ID: <200805290523.m4T5NoM8030178@pork.ICSI.Berkeley.EDU> Given Christian's follow-on note, this might not be apt. But from your original description, it sounds like split_all() will do the trick. For example, split_all("foobar", /./) yields the table[count] of string: { [10] = a, [6] = o, [11] = , [7] = , [4] = o, [1] = , [9] = , [3] = , [5] = , [8] = b, [12] = r, [2] = f, [13] = } which is enough to then iterate over each character. Vern From sullivan at cs.ucsb.edu Wed May 28 23:25:24 2008 From: sullivan at cs.ucsb.edu (Lorenzo Cavallaro) Date: Wed, 28 May 2008 23:25:24 -0700 Subject: [Bro] str_split In-Reply-To: <200805290523.m4T5NoM8030178@pork.ICSI.Berkeley.EDU> References: <20080524001024.GA11673@galilei.laser.dico.unimi.it> <200805290523.m4T5NoM8030178@pork.ICSI.Berkeley.EDU> Message-ID: <20080529062414.GA4561@galilei.laser.dico.unimi.it> Vern, thanks for the reply. I tried that before stucking on str_split. Unfortunately, I need to perform different operation depending on the character position that's why split_all didn't apparently give me any useful result. Actually, the string is splitted but, if I got it right, the order of splitted chars is not guaranteed. Moreover, what are those empty slots? TIA, bye Lorenzo On Wed, May 28, 2008 at 10:23:45PM -0700, Vern Paxson wrote: > Given Christian's follow-on note, this might not be apt. But from > your original description, it sounds like split_all() will do the > trick. For example, > > split_all("foobar", /./) > > yields the table[count] of string: > > { > [10] = a, > [6] = o, > [11] = , > [7] = , > [4] = o, > [1] = , > [9] = , > [3] = , > [5] = , > [8] = b, > [12] = r, > [2] = f, > [13] = > } > > which is enough to then iterate over each character. > > Vern -- Lorenzo `Gigi Sullivan' Cavallaro GPG key at http://security.dico.unimi.it/~sullivan/sullivan.asc Until I loved, life had no beauty; I did not know I lived until I had loved. (Theodor Korner) See the reality in your eyes, when the hate makes you blind. (A.H.X) From vern at icir.org Thu May 29 07:58:35 2008 From: vern at icir.org (Vern Paxson) Date: Thu, 29 May 2008 07:58:35 -0700 Subject: [Bro] str_split In-Reply-To: <20080529062414.GA4561@galilei.laser.dico.unimi.it> (Wed, 28 May 2008 23:25:24 PDT). Message-ID: <200805291458.m4TEweMX014642@pork.ICSI.Berkeley.EDU> > Actually, the string is splitted but, if I got it right, the order of > splitted chars is not guaranteed. Not quite. Since it's a table[count], it's implemented as a hash table, and prints out in an arbitrary order. However, if you iterate from 1 .. its length, you can pull out its elements in order. (I thought there was a built-in that makes doing this easy, but I'm not seeing it. :-( ) > Moreover, what are those empty > slots? The characters of the original string! The semantics of split_all is that it splits on anything that matches the regular expression, returning the strings between the split points intermingled with the separators themselves. For split_all("foobar", /./), *every* character is a separator, so the strings between split points are empty, and the original characters show up in the separator (even) slots. Vern From adayadil.thomas at gmail.com Thu May 29 09:24:15 2008 From: adayadil.thomas at gmail.com (Adayadil Thomas) Date: Thu, 29 May 2008 12:24:15 -0400 Subject: [Bro] Question regarding TCP behavior Message-ID: Greetings. I have a question about TCP. Since this is related to IDS analysis, I thought I'd ask the group. When a TCP end point (A) sends x bytes of data to the other end point (B), does B immediately ACK the received bytes or will it do so only when the data is passed to the upper layer ? Thanks Thomas From vern at icir.org Thu May 29 09:43:17 2008 From: vern at icir.org (Vern Paxson) Date: Thu, 29 May 2008 09:43:17 -0700 Subject: [Bro] Question regarding TCP behavior In-Reply-To: (Thu, 29 May 2008 12:24:15 EDT). Message-ID: <200805291643.m4TGhMrN016679@pork.ICSI.Berkeley.EDU> > When a TCP end point (A) sends x bytes of data to the other end point (B), > does B immediately ACK the received bytes or will it do so only when the data > is passed to the upper layer ? To first order, the former. ACKs are generated by the TCP stack as it is able to place data in sequence, with some rules for delaying certain ACKs by a small amount in hope that more data will arrive in sequence that can also be covered by a single ACK. Generation of an ACK does *not* mean that the upper layer has consumed it. (In fact you can glean whether or not it did based on whether the offered window changes. If it doesn't, but the ACK advances the sequence point, then presumably the upper layer consumed it.) Vern From sullivan at cs.ucsb.edu Thu May 29 19:10:08 2008 From: sullivan at cs.ucsb.edu (Lorenzo Cavallaro) Date: Thu, 29 May 2008 19:10:08 -0700 Subject: [Bro] Data truncated in signature_match and misc questions Message-ID: <20080530021008.GA6747@galilei.laser.dico.unimi.it> Hi all, I'm playing a little bit with Bro and I ran into some issues and I don't know whether these are either bugs or things I don't do in the proper way. Maybe you guys can help me out :-) 1. Basically, I'm trying to do something (apparently :-)) very simple: matching any stream whose carrying a sequence of bytes of length X. For simplicity, lets say that I just want to match any stream which contains at least AAAA. Stream reassembly is very important for me, but I suppose Bro takes care of it when matching against signatures. I'm aware the data argument returned to the signature_match event handler should contain the part of the data that matched... and that's where things got weird (I would have preferred to leverage on signature_match events than instead of digging into the policy). Consider this signature: signature test-AAAA { event "sig-AAAA" payload /.*AAAA/ } and this policy file for the signature_match even handler: @load signatures #@load print-filter event signature_match(state: signature_state, msg: string, data: string) { print fmt("[+] signature_match(%s) called", msg); print fmt("payload length: %d", byte_len(data)); print fmt("payload (first 400 bytes): %s", sub_bytes(data, 0, 400)); } The output I got is the following: [+] signature_match(sig-AAAA) called payload length: 153 payload (first 400 bytes): HTTP/1.1 404 Not Found^M^JDate: Wed, 28 May 2008 22:07:28 GMT^M^JServer: Apache^M^JContent-Length: 270^M^JConnection: close^M^JContent-Type: text/html... I don't see any AAAA in there... even if that's the payload which triggered the signature of course (as shown by tcpdump as well -- not included here). The point is that I'd like to extract any matching pattern from the payload which triggered the signature. Once the pattern is extracted I'd have to iterate over each element of the string do something. This was a dead end to me (but I'm surely missing some point, tho). I also tried with a payload of /.*A{4}/ and /.*[A]{4}/ as I wanted to check whether the metacharacters {} worked properly or not. It turned out they are ok here (signatures) but they don't work, for instance, with gsub. 2. Does tcp_contents reassembles flows (I don't think so)? I'd use tcp_contents right away, but I'd just want to be sure I've no splitted matching payload (e.g., AA in one TCP segment and the next AA in the second one). That's why I wanted to go with the signature thing as this should be automatically taken care of by Bro. If the signature approach doesn't work out, tho, I've to reassemble packets by myself but it seems to me a waisting of times as Bro surely does it (or not?). 3. I'm not able to see packets that are generated by the same host Bro is running on. Is this a normal behavior (performance tuning)? If so, is there a way to disable it just for testing purposes? I double-checked that the filters were right, of course :-). I ran Bro with -f 'tcp' (I'm not concerned about UDP right now, even tho I'll consider it later on). Also, I played with capture_filters and restrict_filters variables either by refining or redefining them. Just to be sure I loaded print-filter to re-check the capture filter was indeed the one I intended to. It was (tcp). Still, I'm not able to get traffic that's sent by the same host where Bro is running on (I've a very basic configuration. Only one interface eth0 and localnets is set properly with just one local net addr, having just one physical net device). 4. Regex works weird. It seems that {} notation, especially when used in conjuction with [^] sometimes works but other doesn't. For instance, it doesn't work with gsub (if I didn't screw anything up, of course). Any ideas? For instance, something like: local tmp = gsub(payload, /[^A]{4}/, " "); doesn't work while the {} metachars worked for signature matching. I know, lots of questions :-) TIA, bye Lorenzo -- Lorenzo `Gigi Sullivan' Cavallaro GPG key at http://security.dico.unimi.it/~sullivan/sullivan.asc Until I loved, life had no beauty; I did not know I lived until I had loved. (Theodor Korner) See the reality in your eyes, when the hate makes you blind. (A.H.X) From shoeyfighter at gmail.com Thu May 29 19:23:31 2008 From: shoeyfighter at gmail.com (Shoey Fighter) Date: Thu, 29 May 2008 19:23:31 -0700 Subject: [Bro] Offline trace: segmentation fault Message-ID: Hello. I am trying to analyze the auckland 4 trace files (http://pma.nlanr.net/Traces/long/auck4.html) in Bro. They are recorded in DAG format, so first I have to convert them to pcap. I have been trying to use libtrace which has various utilities for conversion between various formats. Also, since the auckland4 trace is split into incoming and outgoing directions (with either -0 or -1 at the end of the file), they must be merged together to encompass the complete trace. Here is what I do: tracemerge pcapfile:20010301-110023.pcap.gz legacyatm:20010301-110023-0.gz legacyatm:20010301-110023-1.gz gunzip 20010301-110023.pcap.gz /usr/local/bro/bin/bro -r 20010301-110023.pcap conn scan trw worm analy print-resources Running Bro produces a segmentation fault. It creates all of the output files for the various analyzers (e.g. conn.log), but all of the are 0 bytes. At first, I thought the issue may be due to the large file size of the merged trace (4.1G), so I tried it on just one direction as well (without trying to merge them): traceconvert legacyatm:20010301-110023-0.gz pcapfile:20010301-110023-0.pcap.gz gunzip 20010301-110023-0.pcap.gz /usr/local/bro/bin/bro -r 20010301-110023-0.pcap conn scan trw worm analy print-resources Again, this produces a segmentation fault, and the file size is now 2.0G. I also tried running it (both the merged and single) with only the connection analyzer, which is really the one I am interested in. Again, this led to a seg fault. Some other notes that may be applicable: -The trace files are stored on an nfs mounted drive -I am using bro-1.3.2 -The OS is fedora 4 (32bit), and the machine has 2gb of memory -I can successfully run Bro against the lbnl (http://www.icir.org/enterprise-tracing/download.html) traces using the analyzers from above -If I use the coral reef toolkit, I can print the contents of the converted trace files just fine, which would indicate they are converted successfully Any thoughts? Thanks. From vern at icir.org Thu May 29 19:30:57 2008 From: vern at icir.org (Vern Paxson) Date: Thu, 29 May 2008 19:30:57 -0700 Subject: [Bro] Data truncated in signature_match and misc questions In-Reply-To: <20080530021008.GA6747@galilei.laser.dico.unimi.it> (Thu, 29 May 2008 19:10:08 PDT). Message-ID: <200805300231.m4U2V3Ep024909@pork.ICSI.Berkeley.EDU> A quick comment: when sending along questions/puzzles like these, it *really* helps to include either full working scripts and/or traces that you used to demonstrate the problems. Otherwise we wind up just guessing what might be going on if a similar test case works fine for us. Vern From vern at icir.org Thu May 29 19:37:57 2008 From: vern at icir.org (Vern Paxson) Date: Thu, 29 May 2008 19:37:57 -0700 Subject: [Bro] Offline trace: segmentation fault In-Reply-To: (Thu, 29 May 2008 19:23:31 PDT). Message-ID: <200805300238.m4U2c2us024980@pork.ICSI.Berkeley.EDU> (1) Can you read the trace successfully using tcpdump? (2) If so, what's the shortest subset of it that causes Bro to crash? You can generate short subsets using tcpdump -c to extract just the first packets. (3) (And if you can't read it with tcpdump, then the problem is elsewhere ...) Vern From shoeyfighter at gmail.com Thu May 29 22:04:55 2008 From: shoeyfighter at gmail.com (Shoey Fighter) Date: Thu, 29 May 2008 22:04:55 -0700 Subject: [Bro] Offline trace: segmentation fault In-Reply-To: <200805300238.m4U2c2us024980@pork.ICSI.Berkeley.EDU> References: <200805300238.m4U2c2us024980@pork.ICSI.Berkeley.EDU> Message-ID: 1) Yes, if I use tcpdump -r on the trace it spits out the packets fine. One thing I noticed is that many of the packets are truncated (listed as IP truncated-ip), and the number of bytes missing is not homogenous between the truncated packets. Could this be the problem? 2) I tried: 10000, 1000, 100, 10, 1 and none worked. I noticed that the first packet has the "IP truncated-ip" message. Is there a way to skip some n number of packets? I have included a 100 packet sample if it helps. Thanks. On Thu, May 29, 2008 at 7:37 PM, Vern Paxson wrote: > (1) Can you read the trace successfully using tcpdump? > > (2) If so, what's the shortest subset of it that causes Bro to crash? > You can generate short subsets using tcpdump -c to extract > just the first packets. > > (3) (And if you can't read it with tcpdump, then the problem is elsewhere ...) > > Vern > -------------- next part -------------- A non-text attachment was scrubbed... Name: test.pcap Type: application/octet-stream Size: 7624 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20080529/6fafa708/attachment.obj From vern at icir.org Thu May 29 22:23:27 2008 From: vern at icir.org (Vern Paxson) Date: Thu, 29 May 2008 22:23:27 -0700 Subject: [Bro] Offline trace: segmentation fault In-Reply-To: (Thu, 29 May 2008 22:04:55 PDT). Message-ID: <200805300523.m4U5NWP8026650@pork.ICSI.Berkeley.EDU> > 1) Yes, if I use tcpdump -r on the trace it spits out the packets > fine. One thing I noticed is that many of the packets are truncated > (listed as IP truncated-ip), and the number of bytes missing is not > homogenous between the truncated packets. Could this be the problem? Indeed. The message is indicating an inconsistency between the link layer framing and the IP framing. This doubtless means that the trace conversion process has failed to construct a correct link-layer header. When I run Bro on the trace, I get: bro: problem with trace file test.pcap - unknown data link type 0xb and it exits. Vern From edthoma at sandia.gov Fri May 30 10:41:04 2008 From: edthoma at sandia.gov (Eric Thomas) Date: Fri, 30 May 2008 10:41:04 -0700 (PDT) Subject: [Bro] libmagic for HTTP Message-ID: <20080530102251.J70205@piglet2.ran.sandia.gov> I like FileAnalyzer and its use of libmagic. But I'd like to explore ways it can be used for protocols other than FTP, SMTP, etc. Would it be possible to expose some BIFs so that the magic number analyzer could be used elsewhere, such as http_entity_data? Or is this already there and I'm just missing it? Thanks! Eric edthoma at sandia.gov From seth at net.ohio-state.edu Fri May 30 11:09:54 2008 From: seth at net.ohio-state.edu (Seth Hall) Date: Fri, 30 May 2008 14:09:54 -0400 Subject: [Bro] libmagic for HTTP In-Reply-To: <20080530102251.J70205@piglet2.ran.sandia.gov> References: <20080530102251.J70205@piglet2.ran.sandia.gov> Message-ID: On May 30, 2008, at 1:41 PM, Eric Thomas wrote: > I like FileAnalyzer and its use of libmagic. But I'd like to explore > ways > it can be used for protocols other than FTP, SMTP, etc. Would it be > possible to expose some BIFs so that the magic number analyzer could > be > used elsewhere, such as http_entity_data? Or is this already there > and I'm > just missing it? Thanks! Here is a patch for Bro's trunk to add two libmagic BiFs. (identify_magic_descr, identify_magic_mime). I have a corresponding Bro script for identifying files transferred over HTTP if you're interested in it too. .Seth -------------- next part -------------- A non-text attachment was scrubbed... Name: libmagic_bifs.patch Type: application/octet-stream Size: 1878 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20080530/ea8fdc0a/attachment.obj -------------- next part -------------- --- Seth Hall Network Security - Office of the CIO The Ohio State University Phone: 614-292-9721 From robin at icir.org Fri May 30 13:49:24 2008 From: robin at icir.org (Robin Sommer) Date: Fri, 30 May 2008 13:49:24 -0700 Subject: [Bro] Data truncated in signature_match and misc questions In-Reply-To: <20080530021008.GA6747@galilei.laser.dico.unimi.it> References: <20080530021008.GA6747@galilei.laser.dico.unimi.it> Message-ID: <20080530204923.GA18821@icir.org> (I think I lost track which of these are already solved (if any) so I'll just repsonse briefly. Please ask again for the points which aren't yet clear. Also, when having several independent questions, it's usually easier to keep track if you mail them to list separately.) On Thu, May 29, 2008 at 19:10 -0700, Lorenzo Cavallaro wrote: > Stream reassembly is very important for me, but I suppose Bro > takes care of it when matching against signatures. That's right. > that's where things got weird (I would have preferred to leverage > on signature_match events than instead of digging into the > policy). (Not sure what you're referring to here.) > [+] signature_match(sig-AAAA) called > payload length: 153 > payload (first 400 bytes): HTTP/1.1 404 Not Found^M^JDate: Wed, 28 > May 2008 22:07:28 GMT^M^JServer: Apache^M^JContent-Length: > 270^M^JConnection: close^M^JContent-Type: text/html... > > I don't see any AAAA in there... even if that's the payload which Where in the packet stream is the AAAA (according to tcpdump)? Generally, the data passed to the signature_match event is the last chunk of bytes which triggered the signature match. This might include only parts of the text which matches the pattern and in some cases even none at all (when other conditions are involved as well; I wouldn't expect this with your signature). As Vern wrote, it's easiest to track down the specifics of what you're seeing if you could send a small trace file along with the signature. > The point is that I'd like to extract any matching pattern from the > payload which triggered the signature. Once the pattern is extracted > I'd have to iterate over each element of the string do something. That's not really possible without building further script-level infrastructure yourself. The problem here is that Bro does not buffer the connection's payload internally so when you get a signature match, you don't have access to any earlier data. You'd need to do this buffering yourself but it depends on the specifics of your application whether that it feasible. > to check whether the metacharacters {} worked properly or not. It > turned out they are ok here (signatures) but they don't work, for > instance, with gsub. Again, a trace and sample script would be good which demonstrates the gsub problem. > 2. Does tcp_contents reassembles flows (I don't think so)? I'd use It does (though see the options dpd_* in policy/bro.init for specifics of when Bro reassembles streams). > 3. I'm not able to see packets that are generated by the same host > Bro is running on. Is this a normal behavior (performance tuning)? > If so, is there a way to disable it just for testing purposes? That's as OS issue. Iirc, you indeed don't see packets generated locally on some OSs, though I don't remember the details here. You can check with tcpdump whether libpcap applications like Bro see the packets. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From sullivan at cs.ucsb.edu Fri May 30 16:39:12 2008 From: sullivan at cs.ucsb.edu (Lorenzo Cavallaro) Date: Fri, 30 May 2008 16:39:12 -0700 Subject: [Bro] Data truncated in signature_match and misc questions In-Reply-To: <20080530204923.GA18821@icir.org> References: <20080530021008.GA6747@galilei.laser.dico.unimi.it> <20080530204923.GA18821@icir.org> Message-ID: <20080530233912.GB20934@galilei.laser.dico.unimi.it> Hi Robin, On Fri, May 30, 2008 at 01:49:24PM -0700, Robin Sommer wrote: > (I think I lost track which of these are already solved (if any) so > I'll just repsonse briefly. Please ask again for the points which > aren't yet clear. Also, when having several independent questions, > it's usually easier to keep track if you mail them to list > separately.) Yes, you are right... that would have been much better, my bad :-\ I suppose it's too late for this "thread", tho (If not, let me know and I'll split the questions in different emails ;-)) This is again a long email but I'm trying to give as much information as possible to allow you to reproduce what I got... > > Stream reassembly is very important for me, but I suppose Bro > > takes care of it when matching against signatures. > > That's right. > > > that's where things got weird (I would have preferred to leverage > > on signature_match events than instead of digging into the > > policy). > > (Not sure what you're referring to here.) I meant I would have preferred to go for a signature-matching approach that reassembles streams for me, than to go for a solution which requires me to keep track of streams (with tcp_contents), for instance. However, as I read at the end of this email, maybe tcp_contents would do as well without requiring extra work to do... > > [+] signature_match(sig-AAAA) called > > payload length: 153 > > payload (first 400 bytes): HTTP/1.1 404 Not Found^M^JDate: Wed, 28 > > May 2008 22:07:28 GMT^M^JServer: Apache^M^JContent-Length: > > 270^M^JConnection: close^M^JContent-Type: text/html... > > > > I don't see any AAAA in there... even if that's the payload which > > Where in the packet stream is the AAAA (according to tcpdump)? > > Generally, the data passed to the signature_match event is the last > chunk of bytes which triggered the signature match. This might > include only parts of the text which matches the pattern and in some > cases even none at all (when other conditions are involved as well; > I wouldn't expect this with your signature). > > As Vern wrote, it's easiest to track down the specifics of what > you're seeing if you could send a small trace file along with the > signature. Here's a summary: + HTTP request (I know, nc would have probably been cleaner, telnet output omitted) $ telnet security.dico.unimi.it 80 GET /AAAA HTTP/1.0 + packet trace, herein attached (trace.out) has been obtained as # tcpdump -s 1500 -w trace.out -ni eth0 tcp and host security.dico.unimi.it + the trace contains 13 TCP segments and the pattern AAAA appears in the 4th,5th segments (request) and in the 11th (response). + the Bro signature is stored in test.sig and (as in the previous email), looks like the following: signature test-AAAA { event "sig-AAAA" payload /.*A{4}/ } pls, note that I tried also with the pattern /.*AAAA/ -- The reason for this is given ahead when providing an example of a regex pattern which doesn't work properly (as expected) with a Bro built-in function (e.g., gsub). + Bro (v1.2.1) has been launched as: # bro -r trace.out -s test.sig hostname where hostname is the file which loads all the relevant Bro policy scripts. It loads test-sig.bro as well which implements the signature_match event handler: @load alarm @load conn @load adu @load signatures #@load print-filter redef capture_filters = { }; redef restrict_filters = { ["idea"] = "host security.dico.unimi.it" }; redef restrict_filters += { ["tcp"] = "tcp" }; event signature_match(state: signature_state, msg: string, data: string) { print fmt("[+] signature_match(%s) called", msg); print fmt("[+] payload length: %d", byte_len(data)); print fmt("[+] payload (retr w/ sub_bytes(data, 0, 400)):\n%s", sub_bytes(data, 0, 400)); } + Bro gives the following output: [+] signature_match(sig-AAAA) called [+] payload length: 148 [+] payload (retr w/ sub_bytes(data, 0, 400)): HTTP/1.1 404 Not Found^M^JDate: Fri, 30 May 2008 22:20:38 GMT^M^JServer: Apache/1.3.34 (Debian) PHP/4.4.4-8+etch4 mod_ssl/2.8.25 OpenSSL/0.9.8c^M... So, at the end: + The data returned by the matched signature doesn't contain the signature itself. + The signature is not triggered for the request I made. The request has been issued by the same host where Bro is running on. Of course, I'm able to get and see everything with tcpdump and wireshark. Just for completeness, I'm running a GNU/Debian Linux testing system, libpcap version 0.9.8-3 (debian package), tcpdump version 3.9.8 (debian package), wireshark version 1.0.0 (debian package). > > The point is that I'd like to extract any matching pattern from the > > payload which triggered the signature. Once the pattern is extracted > > I'd have to iterate over each element of the string do something. > > That's not really possible without building further script-level > infrastructure yourself. The problem here is that Bro does not > buffer the connection's payload internally so when you get a > signature match, you don't have access to any earlier data. You'd > need to do this buffering yourself but it depends on the specifics > of your application whether that it feasible. I know that I cannot automatically extract a pattern by using the signature-matching approach. That I've to do it on my own by writing a Bro policy script. I did that and it works. It means that I'm able to extract the pattern I want from a given payload Bro passes me. Of course, if Bro doesn't give me this pattern, no extraction is possible (see previous points). > > to check whether the metacharacters {} worked properly or not. It > > turned out they are ok here (signatures) but they don't work, for > > instance, with gsub. > > Again, a trace and sample script would be good which demonstrates > the gsub problem. Same scenario as above. Signature mechanism turned off. I'm loading the following Bro policy script which uses ADU (note: if I got it right, ADU should work only with HTTP-based communication. Although this is not my final goal -- and I'll go with tcp_contents or with the signature approach -- the example has been tested on an HTTP-based communication). Script follows: @load adu #@load print-filter redef tcp_content_deliver_all_orig = T; redef tcp_content_deliver_all_resp = T; redef adu::adu_max_size = 20000; redef capture_filters = { }; redef restrict_filters = { ["idea"] = "host security.dico.unimi.it" }; function do_handle_adu(ename: string, c: connection, a: adu::adu_state) { local candidate = /(.|\n|\r)*A{4,}/; if ( |a$adu| > 0 ) { local substrtmp: string; local tmp: string; if ( candidate in a$adu ) { print fmt("[+] %s: candidate in a$adu", ename); print fmt("[+] orig payload:\n%s", a$adu); tmp = gsub(a$adu, /[^A]{4,}/, " "); print fmt("[+] tmp ([^A]{4,} regex): %s\n", tmp); tmp = gsub(a$adu, /[^A]+/, " "); print fmt("[+] tmp: ([^A]+ regex) %s\n", tmp); tmp = gsub(a$adu, /[^AAAA]/, " "); print fmt("[+] tmp: ([^AAAA] regex) %s\n", tmp); } } } event adu_tx(c: connection, a: adu::adu_state) { do_handle_adu("adu_tx", c, a); } event adu_rx(c: connection, a: adu::adu_state) { do_handle_adu("adu_rx", c, a); } The output is attached in the file test-adu.output. While I do understand the last output ([^AAAA] regex) and the second one ([^A]+), I don't quite understand the first one ([^A]{4,}) as I would expect everything but the four consecutive A to be substituted with spaces. I might have messed up with regex, tho... > > 2. Does tcp_contents reassembles flows (I don't think so)? I'd use > > It does (though see the options dpd_* in policy/bro.init for > specifics of when Bro reassembles streams). Cool, thanks. So, would handling tcp_contents be enough (given the right dpd_* tuning) if I'm just interested in looking for any sequence of, say, AAAA in the a TCP stream? > > 3. I'm not able to see packets that are generated by the same host > > Bro is running on. Is this a normal behavior (performance tuning)? > > If so, is there a way to disable it just for testing purposes? > > That's as OS issue. Iirc, you indeed don't see packets generated > locally on some OSs, though I don't remember the details here. You > can check with tcpdump whether libpcap applications like Bro see the > packets. I have no issues at all when using other libpcap-based application on my system (GNU/Debian testing Linux -- details about versions are given above). TIA, bye Lorenzo -- Lorenzo `Gigi Sullivan' Cavallaro GPG key at http://security.dico.unimi.it/~sullivan/sullivan.asc Until I loved, life had no beauty; I did not know I lived until I had loved. (Theodor Korner) See the reality in your eyes, when the hate makes you blind. (A.H.X) -------------- next part -------------- A non-text attachment was scrubbed... Name: trace.out Type: application/octet-stream Size: 1697 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20080530/33a4a292/attachment.obj -------------- next part -------------- [+] adu_rx: candidate in a$adu [+] orig payload: HTTP/1.1 404 Not Found^M^JDate: Fri, 30 May 2008 22:20:38 GMT^M^JServer: Apache/1.3.34 (Debian) PHP/4.4.4-8+etch4 mod_ssl/2.8.25 OpenSSL/0.9.8c^M^JConnection: close^M^JContent-Type: text/html; charset=iso-8859-1^M^J^M^J^J^J404 Not Found^J^J

Not Found

^JThe requested URL /AAAA was not found on this server.

^J

^J
Apache/1.3.34 Server at idea.sec.dico.unimi.it Port 80
^J^J [+] tmp ([^A]{4,} regex): A A A AAAA A A A A A [+] tmp: ([^A]+ regex) A A A AAAA A A A A A [+] tmp: ([^AAAA] regex) A A A AAAA A A A A A From seth at net.ohio-state.edu Fri May 30 18:10:08 2008 From: seth at net.ohio-state.edu (Seth Hall) Date: Fri, 30 May 2008 21:10:08 -0400 Subject: [Bro] libmagic for HTTP In-Reply-To: <2BF0A7935DCC2448AF7A835AADC644B3762C89C9DA@ES03SNLNT.srn.sandia.gov> References: <20080530102251.J70205@piglet2.ran.sandia.gov> <2BF0A7935DCC2448AF7A835AADC644B3762C89C9DA@ES03SNLNT.srn.sandia.gov> Message-ID: <23D03278-0518-45C0-A46A-E66EA4608541@net.ohio-state.edu> (I'm sending this to the list again since I sent it to the wrong list last time) On May 30, 2008, at 2:15 PM, Thomas, Eric D wrote: > Yes, please send me your Bro script. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: http-identified-files.bro Type: application/octet-stream Size: 3004 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20080530/c6b642b3/attachment.obj -------------- next part -------------- --- Seth Hall Network Security - Office of the CIO The Ohio State University Phone: 614-292-9721