From fabian at net.t-labs.tu-berlin.de Mon Oct 1 06:27:46 2007 From: fabian at net.t-labs.tu-berlin.de (Fabian Schneider) Date: Mon, 1 Oct 2007 15:27:46 +0200 (CEST) Subject: [Bro] How to construct constant "time" values Message-ID: Hi, I am curious how it is possible to constuct some constant value x that make the following line valid: have_request ? network_time() : x apparently all the forms 0 sec, 0 s, 0sec, 0secs, 0 secs, etc do not work, because they are interpreted as intervals and not times. The wiki didn't yield any solution, because the Section: http://www.bro-ids.org/wiki/index.php/Reference_Manual:_Predefined_Variables_and_Functions#Functions_for_manipulating_time is empty. bye Fabian -- Fabian Schneider, An-Institut Deutsche Telekom Laboratories Technische Universit?t Berlin, Fakult?t IV -- Elektrotechnik und Informatik address: Sekr. TEL 4, FG INET, Ernst-Reuter-Platz 7, 10587 Berlin e-mail: fabian at net.t-labs.tu-berlin.de, WWW: http://www.net.in.tum.de/~schneifa phone: +49 30 8353 - 58513, mobile: +49 160 479 43 97 From fabian at net.t-labs.tu-berlin.de Mon Oct 1 06:35:00 2007 From: fabian at net.t-labs.tu-berlin.de (Fabian Schneider) Date: Mon, 1 Oct 2007 15:35:00 +0200 (CEST) Subject: [Bro] Enhancing/Redefing records and Overloading functions Message-ID: Hi, is it possible to enhance or to redef records that are allready definied in some policy scripts? Just to give you some more context: I tried to add some optional fields to the http_message record (defined in http.bro) : cookie: string &optional; # Cookie set in http request setcookie: string &optional; # Cookie to set from http reply Is there anyway to do this without changing the original policy scripts. Another interessting question would be if there is some way of overloading functions in policy scripts? bye Fabian -- Fabian Schneider, An-Institut Deutsche Telekom Laboratories Technische Universit?t Berlin, Fakult?t IV -- Elektrotechnik und Informatik address: Sekr. TEL 4, FG INET, Ernst-Reuter-Platz 7, 10587 Berlin e-mail: fabian at net.t-labs.tu-berlin.de, WWW: http://www.net.in.tum.de/~schneifa phone: +49 30 8353 - 58513, mobile: +49 160 479 43 97 From vern at icir.org Mon Oct 1 07:55:42 2007 From: vern at icir.org (Vern Paxson) Date: Mon, 01 Oct 2007 07:55:42 -0700 Subject: [Bro] How to construct constant "time" values In-Reply-To: (Mon, 01 Oct 2007 15:27:46 +0200). Message-ID: <200710011455.l91Etlqh016123@pork.ICSI.Berkeley.EDU> > I am curious how it is possible to constuct some constant value x that > make the following line valid: > > have_request ? network_time() : x It's not. Currently, there are no constructors for absolute time values. This is because a convincing need for them hasn't come up. If you have one, let's hear it!, and then we can considering adding this functinonality. Vern From vern at icir.org Mon Oct 1 07:57:23 2007 From: vern at icir.org (Vern Paxson) Date: Mon, 01 Oct 2007 07:57:23 -0700 Subject: [Bro] Enhancing/Redefing records and Overloading functions In-Reply-To: (Mon, 01 Oct 2007 15:35:00 +0200). Message-ID: <200710011457.l91EvSiC016153@pork.ICSI.Berkeley.EDU> > is it possible to enhance or to redef records that are allready definied > in some policy scripts? Not in terms of adding fields to them. We've done some work on adding this sort of object-oriented features, and there's some mechanism under the covers to support it. But to date it hasn't been clear it's worth the considerable effort to get it fully working. > Another interessting question would be if there is some way of overloading > functions in policy scripts? This would be something that might also naturally come with OO-orientation ... Vern From ager at net.in.tum.de Mon Oct 1 09:20:12 2007 From: ager at net.in.tum.de (Bernhard Ager) Date: Mon, 1 Oct 2007 18:20:12 +0200 Subject: [Bro] UDP flow anomaly In-Reply-To: <1bb5dd90709200432o4246dec2t1aeb0dd14479181a@mail.gmail.com> References: <1bb5dd90709180039g7770d9c8tf5e2fd31f0fa2164@mail.gmail.com> <20070919032510.GK1322@icir.org> <1bb5dd90709200432o4246dec2t1aeb0dd14479181a@mail.gmail.com> Message-ID: <20071001162009.GT29588@in.tum.de> On Thu, Sep 20, 2007 at 07:32:11PM +0800, CS Lee wrote: > Back to word, I would like to know if anyone working on skype policy script, > in case there's merge of same interest. Actually I have a student - Miguel - working on a skype analyzer as part of his diplom thesis. Regards, Bernhard -- Technische Universit?t Berlin An-Institut Deutsche Telekom Laboratories FG INET, Research Group Anja Feldmann Sekr. TEL 4 Ernst-Reuter-Platz 7 D-10587 Berlin From robin at icir.org Mon Oct 1 09:32:07 2007 From: robin at icir.org (Robin Sommer) Date: Mon, 1 Oct 2007 09:32:07 -0700 Subject: [Bro] How to construct constant "time" values In-Reply-To: <200710011455.l91Etlqh016123@pork.ICSI.Berkeley.EDU> References: <200710011455.l91Etlqh016123@pork.ICSI.Berkeley.EDU> Message-ID: <20071001163207.GA2800@icir.org> On Mon, Oct 01, 2007 at 07:55 -0700, Vern Paxson wrote: > > have_request ? network_time() : x > > It's not. Currently, there are no constructors for absolute time values. > This is because a convincing need for them hasn't come up. If you have > one, let's hear it!, and then we can considering adding this functinonality. I suppose the application here is to use a time of zero as a null value, i.e., as an indicator that one doesn't have a time. As a work-around, double_to_time(0.0) should work. Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org LBNL/ICSI * Fax +1 (510) 666-2956 * www.icir.org From rreitz at fnal.gov Mon Oct 1 14:13:18 2007 From: rreitz at fnal.gov (Randolph Reitz) Date: Mon, 01 Oct 2007 16:13:18 -0500 Subject: [Bro] inbound PortScans that aren't really... In-Reply-To: <20070927164933.GD13997@icir.org> References: <04488F89-3613-47A4-826B-CC8D4B8F7476@fnal.gov> <20070927164933.GD13997@icir.org> Message-ID: On Sep 27, 2007, at 11:49, Robin Sommer wrote: > > On Wed, Sep 26, 2007 at 16:37 -0500, Randolph Reitz wrote: > >> few others, on the Fermilab traffic. I see a lot of inbound scans >> that appear to be bogus. For example... > > Can you send me a trace of one of these scans? (Just TCP control > packets is fine if there's content you can't pass on). > > Robin > > -- > Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org > LBNL/ICSI * Fax +1 (510) 666-2956 * www.icir.org > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro We have a free copy of splunk indexing the /usr/local/bro/logs/* files. Using splunk provides an easy way to retrieve data from all of the BRO files - conn, notice, info, etc. Tim Rupp did this. He's available for hire! I saw an outbound scan report today and used this splunk command ... . /opt/splunk/bin/setSplunkEnv; splunk search "FER.MI.LAB.IP endtime:: 10/01/2007:14:37:19 searchtimespanminutes::10 maxresults::1000" | cf > ~/h/bro_scan_question.txt I've attached the file. I know, you don't need all 1000 lines, but hey? At the top of the file is some stuff you won't recognize ... Oct 1 14:37:19:AddressDropped:NOTICE_ALARM_ALWAYS::FER.MI.LAB.IP:::::::::dropp ing address 131.225.107.90 (131. 225.107.90 has scanned 250 ports of 195.56.77.182): Oct 1 14:37:19 ? 195.56.77.182 FER.MI.LAB.IP https 1218 443 tcp ? ? S0 X cc=1 Oct 1 14:37:19 ? 195.56.77.182 FER.MI.LAB.IP https 64944 443 tcp ? ? S0 X cc=1 Oct 1 14:37:19 0.000000 195.56.77.182 FER.MI.LAB.IP https 64937 443 tcp ? 0 SHR X Dec 31 18:00:07 <- I don't know where this came from Create_events(dev): IP='FER.MI.LAB.IP' with 1 issues <- This is my code that creates Create_events(dev): issues['FER.MI.LAB.IP'] is <- and event in our TIssue tracking save_issue:oid=132843792 -> issue_id=1751 <- system Oct 1 14:37:19 AddressDropped dropping address FER.MI.LAB.IP (FER.MI.LAB.IP has scanned 250 ports of 195.56.7 7.182) <- message from scan.bro Oct 1 14:37:19 PortScan FER.MI.LAB.IP has scanned 250 ports of 195.56.77.182 Oct 1 14:37:18 1.007632 195.56.77.182 FER.MI.LAB.IP https 1209 443 tcp ? ? RSTO X @20572 <- here you see that the Oct 1 14:37:18 ? 195.56.77.182 FER.MI.LAB.IP https 64938 443 tcp ? ? OTH X cc=1 <- web server running on FER.MI.LAB.IP Oct 1 14:37:18 ? 195.56.77.182 FER.MI.LAB.IP https 64936 443 tcp ? ? OTH X cc=1 <- the web browser (or whatever) is Oct 1 14:37:17 ? 195.56.77.182 FER.MI.LAB.IP https 64927 443 tcp ? ? S1 X <- makeing requests with a different Oct 1 14:37:17 ? 195.56.77.182 FER.MI.LAB.IP https 64932 443 tcp ? ? OTH X cc=1 <- source port. So scan.bro's counter Oct 1 14:37:17 ? 195.56.77.182 FER.MI.LAB.IP https 64926 443 tcp ? ? S0 X cc=1 <- increases with each connection and Oct 1 14:37:17 ? 195.56.77.182 FER.MI.LAB.IP https 64925 443 tcp ? ? OTH X cc=1 <- reports a port scan??? Here is the file... -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bro_scan_question.txt Url: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071001/9dd767de/attachment-0001.txt -------------- next part -------------- Thanks, Randy From rporada at ll.mit.edu Wed Oct 3 07:04:33 2007 From: rporada at ll.mit.edu (Reed Porada) Date: Wed, 3 Oct 2007 10:04:33 -0400 Subject: [Bro] Questions about Bro Capabilities In-Reply-To: <20070927014302.GA8872@icir.org> References: <3F143535-4B01-4A12-856F-E28FD40CA812@ll.mit.edu> <20070927014302.GA8872@icir.org> Message-ID: On Sep 26, 2007, at 9:43 PM, Robin Sommer wrote: > > On Wed, Sep 26, 2007 at 15:16 -0400, you wrote: > >> 1) Is it possible to denote particular packets in a capture? I know > > No, not really. The main problem here is that the link between most > event handlers and the actual packets is pretty weak. In general, > Bro does not give guarantees about when a particular event is raised > and also doesn't keep track which packet triggered it. There's a > function called get_current_packet() which returns the packet Bro > currently munching on but when script code is running it's hard to > predict which packet that actually is. > > The only event which directly refers to packets is new_packet() but > using that is expensive because it is raised for *all* packets. > > That said, perhaps we might be able to come up with some idea if you > sketch in a bit more detail what you're trying to achieve. > I am working on a Traffic Generator (TG) project. Our TG has static content for webpages and fileshares. In addition, we know when our TG hosts attempt to access that data. Given those to things, I want to be able to take a network capture, run it through a system and separate out traffic that we know our TG generated, by correlating intent and traffic content, and other traffic on the network. The end goal being smaller and more relevant network captures for an analyst. In order to do this I want to try and leverage others protocol analyzers and parsers. Bro seems to be a good choice as I believe through a policy and some pregenerated variables (based on the content and host intent) I can validate given traffic to be from our TG system, and leave the rest for others to analyze. I believe that in order to do this I need to get out of Bro the relevant packets, either packet number or timestamp. Given that information, I would be able to run it through a script that would split the pcap based on the output. The added benefit of Bro is that it does some additional analysis that could be useful for capture analysis. Is that a better sketch? Any thoughts? Thanks in advance, -Reed From nweaver at ICSI.Berkeley.EDU Wed Oct 3 07:36:24 2007 From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver) Date: Wed, 3 Oct 2007 07:36:24 -0700 Subject: [Bro] Questions about Bro Capabilities In-Reply-To: References: <3F143535-4B01-4A12-856F-E28FD40CA812@ll.mit.edu> <20070927014302.GA8872@icir.org> Message-ID: <20071003143624.GA30808@kona.ICSI.Berkeley.EDU> On Wed, Oct 03, 2007 at 10:04:33AM -0400, Reed Porada composed: > > No, not really. The main problem here is that the link between most > > event handlers and the actual packets is pretty weak. In general, > > Bro does not give guarantees about when a particular event is raised > > and also doesn't keep track which packet triggered it. There's a > > function called get_current_packet() which returns the packet Bro > > currently munching on but when script code is running it's hard to > > predict which packet that actually is. Although for events which are effectively instentanious (eg, the ones created directly and indirectly by the protocol parsing), get_current_packet() will be PART of the current stream, but due to reordering issues, may not be the last packet in the current stream in TCP sequence order. > I am working on a Traffic Generator (TG) project. Our TG has static > content for webpages and fileshares. In addition, we know when our > TG hosts attempt to access that data. Given those to things, I want > to be able to take a network capture, run it through a system and > separate out traffic that we know our TG generated, by correlating > intent and traffic content, and other traffic on the network. The > end goal being smaller and more relevant network captures for an > analyst. In order to do this I want to try and leverage others > protocol analyzers and parsers. Bro seems to be a good choice as I > believe through a policy and some pregenerated variables (based on > the content and host intent) I can validate given traffic to be from > our TG system, and leave the rest for others to analyze. I believe > that in order to do this I need to get out of Bro the relevant > packets, either packet number or timestamp. Given that information, > I would be able to run it through a script that would split the pcap > based on the output. The added benefit of Bro is that it does some > additional analysis that could be useful for capture analysis. What exactly are the defining characteristics of your synthetic traffic? -- Nicholas C. Weaver nweaver at icsi.berkeley.edu This message has been ROT-13 encrypted twice for higher security. From rporada at ll.mit.edu Wed Oct 3 08:14:45 2007 From: rporada at ll.mit.edu (Reed Porada) Date: Wed, 3 Oct 2007 11:14:45 -0400 Subject: [Bro] Questions about Bro Capabilities In-Reply-To: <20071003143624.GA30808@kona.ICSI.Berkeley.EDU> References: <3F143535-4B01-4A12-856F-E28FD40CA812@ll.mit.edu> <20070927014302.GA8872@icir.org> <20071003143624.GA30808@kona.ICSI.Berkeley.EDU> Message-ID: On Oct 3, 2007, at 10:36 AM, Nicholas Weaver wrote: > > On Wed, Oct 03, 2007 at 10:04:33AM -0400, Reed Porada composed: > >> I am working on a Traffic Generator (TG) project. Our TG has static >> content for webpages and fileshares. In addition, we know when our >> TG hosts attempt to access that data. Given those to things, I want >> to be able to take a network capture, run it through a system and >> separate out traffic that we know our TG generated, by correlating >> intent and traffic content, and other traffic on the network. The >> end goal being smaller and more relevant network captures for an >> analyst. In order to do this I want to try and leverage others >> protocol analyzers and parsers. Bro seems to be a good choice as I >> believe through a policy and some pregenerated variables (based on >> the content and host intent) I can validate given traffic to be from >> our TG system, and leave the rest for others to analyze. I believe >> that in order to do this I need to get out of Bro the relevant >> packets, either packet number or timestamp. Given that information, >> I would be able to run it through a script that would split the pcap >> based on the output. The added benefit of Bro is that it does some >> additional analysis that could be useful for capture analysis. > > What exactly are the defining characteristics of your synthetic > traffic? Our synthetic traffic is not any different than if a normal user was on a machine generating the traffic. Meaning that we use IE to navigate to a page, and we use Windows File Browsing to look at network file shares. Our TG is designed to be run on an isolated network, ala DETER, thus we setup a simulated internet, and other simulated networks. Since we are creating these networks, we control server content, IP addresses, and host-names. The belief that we have is that since we know what our content is (i.e. what is at a given website, or on a given file share) and we know when we tried to access the given data (we have our host agents log intent), that we can separate out our TG traffic. In theory there is no defining characteristic of our synthetic traffic in the packet captures that we could make Bro or really any other packet analyzer look for, basically we do not set the evil bit. However, with the additional knowledge of what the content is, and what a synthetic user was doing, we believe we can find our traffic. After looking at the variables and other things that Bro policy language has, I believe I can construct the lookup tables for host_agent_events and web_content. Therefore, I believe that I can create a policy script to "find" our traffic. What I am not sure is that from the policy I can provide the information necessary to get our traffic out of the capture, i.e make a smaller capture with just the non-TG traffic. Not sure if that answered you question Nicholas, but hopefully it clears some things up. -Reed From nweaver at ICSI.Berkeley.EDU Wed Oct 3 08:26:19 2007 From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver) Date: Wed, 3 Oct 2007 08:26:19 -0700 Subject: [Bro] Questions about Bro Capabilities In-Reply-To: References: <3F143535-4B01-4A12-856F-E28FD40CA812@ll.mit.edu> <20070927014302.GA8872@icir.org> <20071003143624.GA30808@kona.ICSI.Berkeley.EDU> Message-ID: <20071003152619.GB30967@kona.ICSI.Berkeley.EDU> On Wed, Oct 03, 2007 at 11:14:45AM -0400, Reed Porada composed: > > On Oct 3, 2007, at 10:36 AM, Nicholas Weaver wrote: > > > > >On Wed, Oct 03, 2007 at 10:04:33AM -0400, Reed Porada composed: > > > >>I am working on a Traffic Generator (TG) project. Our TG has static > >>content for webpages and fileshares. In addition, we know when our > >>TG hosts attempt to access that data. Given those to things, I want > >>to be able to take a network capture, run it through a system and > >>separate out traffic that we know our TG generated, by correlating > >>intent and traffic content, and other traffic on the network. The > >>end goal being smaller and more relevant network captures for an > >>analyst. In order to do this I want to try and leverage others > >>protocol analyzers and parsers. Bro seems to be a good choice as I > >>believe through a policy and some pregenerated variables (based on > >>the content and host intent) I can validate given traffic to be from > >>our TG system, and leave the rest for others to analyze. I believe > >>that in order to do this I need to get out of Bro the relevant > >>packets, either packet number or timestamp. Given that information, > >>I would be able to run it through a script that would split the pcap > >>based on the output. The added benefit of Bro is that it does some > >>additional analysis that could be useful for capture analysis. > > > >What exactly are the defining characteristics of your synthetic > >traffic? > > Our synthetic traffic is not any different than if a normal user was > on a machine generating the traffic. Meaning that we use IE to > navigate to a page, and we use Windows File Browsing to look at > network file shares. Our TG is designed to be run on an isolated > network, ala DETER, thus we setup a simulated internet, and other > simulated networks. Since we are creating these networks, we control > server content, IP addresses, and host-names. The belief that we > have is that since we know what our content is (i.e. what is at a > given website, or on a given file share) and we know when we tried to > access the given data (we have our host agents log intent), that we > can separate out our TG traffic. In theory there is no defining > characteristic of our synthetic traffic in the packet captures that > we could make Bro or really any other packet analyzer look for, > basically we do not set the evil bit. However, with the additional > knowledge of what the content is, and what a synthetic user was > doing, we believe we can find our traffic. After looking at the > variables and other things that Bro policy language has, I believe I > can construct the lookup tables for host_agent_events and > web_content. Therefore, I believe that I can create a policy script > to "find" our traffic. What I am not sure is that from the policy I > can provide the information necessary to get our traffic out of the > capture, i.e make a smaller capture with just the non-TG traffic. One thought: For offline processing, do a two-pass approach. In the first pass, you use Bro to find the TG flows based on the higher-level attributes, and write out the flow IDs. For the second pass, only capture the flows which don't correspond. -- Nicholas C. Weaver nweaver at icsi.berkeley.edu This message has been ROT-13 encrypted twice for higher security. From robin at icir.org Wed Oct 3 09:51:43 2007 From: robin at icir.org (Robin Sommer) Date: Wed, 3 Oct 2007 09:51:43 -0700 Subject: [Bro] Questions about Bro Capabilities In-Reply-To: <20071003152619.GB30967@kona.ICSI.Berkeley.EDU> References: <3F143535-4B01-4A12-856F-E28FD40CA812@ll.mit.edu> <20070927014302.GA8872@icir.org> <20071003143624.GA30808@kona.ICSI.Berkeley.EDU> <20071003152619.GB30967@kona.ICSI.Berkeley.EDU> Message-ID: <20071003165143.GB12653@icir.org> On Wed, Oct 03, 2007 at 08:26 -0700, Nicholas Weaver wrote: > For offline processing, do a two-pass approach. In the first pass, > you use Bro to find the TG flows based on the higher-level attributes, > and write out the flow IDs. For the second pass, only capture the > flows which don't correspond. Yeah, that was my thought too. (This is an offline scheme, isn't it?) If I understood your approach correctly, you depend on application-layer analysis to find "your" traffic. In that case, doing it in a single pass would likely miss packets because you might only be able to take the decision some way into the stream. At the same time it also sounds like you're always cutting out complete flows rather than just individual packets. So, a two-pass, flow-based approach sounds indeed reasonable. Does this make any sense? Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From mel at hackinthebox.org Wed Oct 3 10:07:41 2007 From: mel at hackinthebox.org (mel) Date: Thu, 04 Oct 2007 01:07:41 +0800 Subject: [Bro] question about bro alarm log Message-ID: <4703CC5D.1030701@hackinthebox.org> Hi, I've noticed that for HTTP_SensitiveURI, there are at least two different types of log entries: t=1190249317.414519 no=HTTP_SensitiveURI na=NOTICE_ALARM_ALWAYS sa=60.50.247.122 sp=37248/tcp da=58.215.65.113 dp=8000/tcp method=GET url=/announce?peer_id=-KT2100-359018798262&port=6881&uploaded=0&downloaded=0&left=33554432&compact=1&numwant=100&key=1458894583&event=started&info_hash=\xd0\x9c;\xd8\xe6z/V\xe8\x89\x9c^K\xc3\xe0?pL\x1b\xaef num=302 msg=60.50.247.122/37248\ >\ 58.215.65.113/8000\ %12:\ GET\ /announce?peer_id=-KT2100-359018798262&port=6881&uploaded=0&downloaded=0&left=33554432&compact=1&numwant=100&key=1458894583&event=started&info_hash=\\xd0\\x9c;\\xd8\\xe6z/V\\xe8\\x89\\x9c^K\\xc3\\xe0?pL\\x1b\\xaef\ (302\ "Found"\ [0]\ btfans.3322.org:8000) tag=@274 and t=1190253817.786857 no=HTTP_SensitiveURI na=NOTICE_ALARM_ALWAYS sa=211.25.195.202 sp=46862/tcp da=60.50.247.122 dp=81/tcp method=GET url=/mro/favicon.ico num=404 msg=211.25.195.202/46862\ >\ 60.50.247.88/81\ %13\ @290:\ GET\ /mro/favicon.ico\ (404\ "Not\ Found"\ [279]\ whatever.zapto.org:81) tag=@290 In the first line, inside msg: 60.50.247.122/37248\ >\ 58.215.65.113/8000\ %12: while the second one: 211.25.195.202/46862\ >\ 60.50.247.88/81\ %13\ @290: Why the difference? --mel From nweaver at ICSI.Berkeley.EDU Wed Oct 3 11:20:48 2007 From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver) Date: Wed, 3 Oct 2007 11:20:48 -0700 Subject: [Bro] question about bro alarm log In-Reply-To: <4703CC5D.1030701@hackinthebox.org> References: <4703CC5D.1030701@hackinthebox.org> Message-ID: <20071003182048.GA31759@kona.ICSI.Berkeley.EDU> On Thu, Oct 04, 2007 at 01:07:41AM +0800, mel composed: > Hi, > > I've noticed that for HTTP_SensitiveURI, there are at least two > different types of log entries: > > t=1190249317.414519 no=HTTP_SensitiveURI na=NOTICE_ALARM_ALWAYS > sa=60.50.247.122 sp=37248/tcp da=58.215.65.113 dp=8000/tcp method=GET > url=/announce?peer_id=-KT2100-359018798262&port=6881&uploaded=0&downloaded=0&left=33554432&compact=1&numwant=100&key=1458894583&event=started&info_hash=\xd0\x9c;\xd8\xe6z/V\xe8\x89\x9c^K\xc3\xe0?pL\x1b\xaef > num=302 msg=60.50.247.122/37248\ >\ 58.215.65.113/8000\ %12:\ GET\ > /announce?peer_id=-KT2100-359018798262&port=6881&uploaded=0&downloaded=0&left=33554432&compact=1&numwant=100&key=1458894583&event=started&info_hash=\\xd0\\x9c;\\xd8\\xe6z/V\\xe8\\x89\\x9c^K\\xc3\\xe0?pL\\x1b\\xaef\ > (302\ "Found"\ [0]\ btfans.3322.org:8000) tag=@274 > > and > > t=1190253817.786857 no=HTTP_SensitiveURI na=NOTICE_ALARM_ALWAYS > sa=211.25.195.202 sp=46862/tcp da=60.50.247.122 dp=81/tcp method=GET > url=/mro/favicon.ico num=404 msg=211.25.195.202/46862\ >\ > 60.50.247.88/81\ %13\ @290:\ GET\ /mro/favicon.ico\ (404\ "Not\ Found"\ > [279]\ whatever.zapto.org:81) tag=@290 > > In the first line, inside msg: > > 60.50.247.122/37248\ >\ 58.215.65.113/8000\ %12: > > while the second one: > > 211.25.195.202/46862\ >\ 60.50.247.88/81\ %13\ @290: > > Why the difference? Beacuse NOTICE([HTTP_SensitiveURI]) occurs in three segments of the code: http.bro, http-repquest, and http-reply, and it is used in http.bro: $msg=fmt("%s:%d -> %s:%d %s: ", session$orig_h, session$orig_p, session$resp_h, session$resp_p, id), http-request.bro: $msg=fmt("%s %s: %s %s", id_string(c$id), c$addl, method, URI), http-reply.bro: $msg = fmt("%s %s: %s", id_string(c$id), c$addl, req_rep), -- Nicholas C. Weaver nweaver at icsi.berkeley.edu This message has been ROT-13 encrypted twice for higher security. From rporada at ll.mit.edu Thu Oct 4 08:03:07 2007 From: rporada at ll.mit.edu (Reed Porada) Date: Thu, 4 Oct 2007 11:03:07 -0400 Subject: [Bro] Questions about Bro Capabilities In-Reply-To: <20071003165143.GB12653@icir.org> References: <3F143535-4B01-4A12-856F-E28FD40CA812@ll.mit.edu> <20070927014302.GA8872@icir.org> <20071003143624.GA30808@kona.ICSI.Berkeley.EDU> <20071003152 Message-ID: <67F7D088-B34F-4ED2-965C-EF9238251EE8@ll.mit.edu> On Oct 3, 2007, at 12:51 PM, Robin Sommer wrote: > > On Wed, Oct 03, 2007 at 08:26 -0700, Nicholas Weaver wrote: > >> For offline processing, do a two-pass approach. In the first pass, >> you use Bro to find the TG flows based on the higher-level >> attributes, >> and write out the flow IDs. For the second pass, only capture the >> flows which don't correspond. > > Yeah, that was my thought too. (This is an offline scheme, isn't it?) > Yes this is an offline scheme at this point. > If I understood your approach correctly, you depend on > application-layer analysis to find "your" traffic. In that case, > doing it in a single pass would likely miss packets because you > might only be able to take the decision some way into the stream. > For http, yes we depend on the application layer to validate the session, as we otherwise have no good way to validate individual packets. > At the same time it also sounds like you're always cutting out > complete flows rather than just individual packets. So, a two-pass, > flow-based approach sounds indeed reasonable. I believe in general that entire flows will be cut out, given that if a single packet is off it is hard to validate the rest as being ours. However, we still would like to possibly make an educated guess as to the culprit packet if possible. > Does this make any sense? In general I understand what you and Nick have proposed. I do not know how to get the flow-ids out. Are the http_request_stream$id's unique? One thing that was suggested by a co-worker after looking at the output, is that we have a timestamp, src ip/port, dst ip/port. In general within a pcap that is sufficient for identifying a packet, my guess as to why you have not suggested this option is that the network_time() that is being used in output does not relate to the stream. Is there anyway to get that to have a closer correlation to the stream? I am also curious as to how to interpret the output from http-body. What does each printout from http_entity_data events represent? Is it a new packet, or an update to the stream that could be the sum of an arbitrary number of packets? Thanks again for your time and help, -Reed From nweaver at ICSI.Berkeley.EDU Thu Oct 4 08:07:42 2007 From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver) Date: Thu, 4 Oct 2007 08:07:42 -0700 Subject: [Bro] Questions about Bro Capabilities In-Reply-To: <67F7D088-B34F-4ED2-965C-EF9238251EE8@ll.mit.edu> References: <3F143535-4B01-4A12-856F-E28FD40CA812@ll.mit.edu> <20070927014302.GA8872@icir.org> <20071003143624.GA30808@kona.ICSI.Berkeley.EDU> <67F7D088-B34F-4ED2-965C-EF9238251EE8@ll.mit.edu> Message-ID: <20071004150742.GA3276@kona.ICSI.Berkeley.EDU> On Thu, Oct 04, 2007 at 11:03:07AM -0400, Reed Porada composed: > >Does this make any sense? > > In general I understand what you and Nick have proposed. I do not > know how to get the flow-ids out. Are the http_request_stream$id's > unique? One thing that was suggested by a co-worker after looking at > the output, is that we have a timestamp, src ip/port, dst ip/port. > In general within a pcap that is sufficient for identifying a packet, > my guess as to why you have not suggested this option is that the > network_time() that is being used in output does not relate to the > stream. Is there anyway to get that to have a closer correlation to > the stream? I am also curious as to how to interpret the output from > http-body. What does each printout from http_entity_data events > represent? Is it a new packet, or an update to the stream that could > be the sum of an arbitrary number of packets? with most hosts, the 5-tuple should be unique (SRC ip/port,DST ip/port,proto). So just record the 5-tuple of anything to exclude in a file, and then use that file in the second pass to filter out those connections. From rporada at ll.mit.edu Thu Oct 4 08:55:43 2007 From: rporada at ll.mit.edu (Reed Porada) Date: Thu, 4 Oct 2007 11:55:43 -0400 Subject: [Bro] Trace Files Message-ID: <3854D748-6837-434C-81D1-1354C825210D@ll.mit.edu> On the Bro wiki it mentions that Bro can be configured to output captured packets that look suspicious. The documentation regarding trace files seems to stop there. I know there is a -w flag, but that seems to be more related to using bro with the -i option, not for getting suspicious traffic. What do I need to do to configure Bro to output a trace file? That would be one additional capability that I would compliment separating out my TG traffic and other traffic mentioned in the 'Question about Bro Capabilities' thread. Thanks, -Reed From muscletot at gmail.com Thu Oct 4 17:14:19 2007 From: muscletot at gmail.com (Mike Wood) Date: Thu, 4 Oct 2007 17:14:19 -0700 Subject: [Bro] nfs analysis In-Reply-To: <1190851469.5755.344.camel@strangepork> References: <7f3e32390709211725w701de3e5geaeb1831d843a8c8@mail.gmail.com> <1190497802.5755.29.camel@strangepork> <7f3e32390709241039m197f30d4r2378bc715d194c7a@mail.gmail.com> <1190851469.5755.344.camel@strangepork> Message-ID: <7f3e32390710041714h52d3ac63j3a1b1da81940cf97@mail.gmail.com> Hi Christian, On 9/26/07, Christian Kreibich wrote: > On Mon, 2007-09-24 at 10:39 -0700, Mike Wood wrote: > > Sadly, yes I do not get any output from nfs.bro. > > > > The tcpdump output for my trace looks like: > > > > 16:01:13.467628 IP client.host.name.4160508447 > server.host.name.nfs: > > 132 getattr [|nfs] > > Also, I'm wondering how the source port can be 4160508447 in your > tcpdump!? Turns out this looks like a tcpdump bug that has an appropriate fix (see http://lists.freebsd.org/pipermail/freebsd-bugs/2006-November/021159.html). So, I think my trace is actually fine. I ran bro in gdb to trace out the execution. It seems the UDP.cc analyzer gets called, but the analysis goes no further than that -- i.e. I get to UDP_Analyzer::DeliverPacket, but I never get to RPC_UDP_Analyzer_binpac::DeliverPacket. I have tried running with the --use-binpac option, but get the same result. Any further ideas? - Mike From sangramkishore at tataelxsi.co.in Fri Oct 5 02:33:24 2007 From: sangramkishore at tataelxsi.co.in (sangramkishore) Date: Fri, 5 Oct 2007 15:03:24 +0530 Subject: [Bro] How to reset value of the timer Message-ID: <001c01c80732$c7765780$2719320a@telxsi.com> Hi I have added ADD_ANALYZER_TIMER(&TCP_Analyzer::AckTimer1,tcp_ACK_timeout,0,TIMER_TCP_EXPI RE); in TCP.cc file. AckTimer1 is my own function which executes when ACK doesn't comes within tcp_ACK_timeout (This sets to 6.5 sec). I want to reset the value of tcp_ACK_timeout when Acknowledgment comes. Can you give me solution for this? Bye LS Kishore The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments contained in it. Contact your Administrator for further information. From ssmit7 at gmail.com Fri Oct 5 05:38:01 2007 From: ssmit7 at gmail.com (Stephen Smith) Date: Fri, 5 Oct 2007 08:38:01 -0400 Subject: [Bro] issue with geoip lookups Message-ID: I'm using the GeoIP lookup functionality in 1.3 and everything looks to be working fine, except that all the addresses are getting looked up "backwards". For example, if Bro looks up the address 64.236.22.63, I will get a log entry Connection to: 64.236.22.63 (Westford, MA, US) which does not match with the output of a manual lookup with geoiplookup. However if I run 63.22.236.64 through geoiplookup, I get GeoIP City Edition, Rev 0: US, MA, Westford I have confirmed this with several different IPs. I'm running Bro 1.3.2 on FreeBSD 6.2 with the ports install of GeoIP 1.4.3. Any suggestions? Thanks, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071005/05a6e6cc/attachment.html From nweaver at ICSI.Berkeley.EDU Fri Oct 5 06:59:39 2007 From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver) Date: Fri, 5 Oct 2007 06:59:39 -0700 Subject: [Bro] issue with geoip lookups In-Reply-To: References: Message-ID: <20071005135939.GA14612@kona.ICSI.Berkeley.EDU> On Fri, Oct 05, 2007 at 08:38:01AM -0400, Stephen Smith composed: > I'm using the GeoIP lookup functionality in 1.3 and everything looks to be > working fine, except that all the addresses are getting looked up > "backwards". For example, if Bro looks up the address 64.236.22.63, I will > get a log entry > > Connection to: 64.236.22.63 (Westford, MA, US) > > which does not match with the output of a manual lookup with geoiplookup. > > However if I run 63.22.236.64 through geoiplookup, I get > > GeoIP City Edition, Rev 0: US, MA, Westford > > I have confirmed this with several different IPs. I'm running Bro 1.3.2 on > FreeBSD 6.2 with the ports install of GeoIP 1.4.3. Any suggestions? This is just simply a print order, (City, region, country) rather than (country, region, city), I believe. What is the function you are using to print out the location? -- Nicholas C. Weaver nweaver at icsi.berkeley.edu This message has been ROT-13 encrypted twice for higher security. From vern at icir.org Fri Oct 5 07:19:00 2007 From: vern at icir.org (Vern Paxson) Date: Fri, 05 Oct 2007 07:19:00 -0700 Subject: [Bro] issue with geoip lookups In-Reply-To: <20071005135939.GA14612@kona.ICSI.Berkeley.EDU> (Fri, 05 Oct 2007 06:59:39 PDT). Message-ID: <200710051419.l95EJ52U002732@pork.ICSI.Berkeley.EDU> > > "backwards". For example, if Bro looks up the address 64.236.22.63, I will > > get a log entry > > > > Connection to: 64.236.22.63 (Westford, MA, US) > > > > which does not match with the output of a manual lookup with geoiplookup. > > > > However if I run 63.22.236.64 through geoiplookup, I get > > > > GeoIP City Edition, Rev 0: US, MA, Westford > > > > I have confirmed this with several different IPs. I'm running Bro 1.3.2 on > > FreeBSD 6.2 with the ports install of GeoIP 1.4.3. Any suggestions? > This is just simply a print order, (City, region, country) rather than > (country, region, city), I believe. I believe he's referring to 64.236.22.63 instead returning information for 63.22.236.64 - which looks a lot like a missing ntohl(). Vern From nweaver at ICSI.Berkeley.EDU Fri Oct 5 07:20:48 2007 From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver) Date: Fri, 5 Oct 2007 07:20:48 -0700 Subject: [Bro] issue with geoip lookups In-Reply-To: <200710051419.l95EJ52U002732@pork.ICSI.Berkeley.EDU> References: <20071005135939.GA14612@kona.ICSI.Berkeley.EDU> <200710051419.l95EJ52U002732@pork.ICSI.Berkeley.EDU> Message-ID: <20071005142048.GA14697@kona.ICSI.Berkeley.EDU> On Fri, Oct 05, 2007 at 07:19:00AM -0700, Vern Paxson composed: > > This is just simply a print order, (City, region, country) rather than > > (country, region, city), I believe. > > I believe he's referring to 64.236.22.63 instead returning information > for 63.22.236.64 - which looks a lot like a missing ntohl(). Ah, yeah. (Didn't notice that). What is the function you are using to print the IP? -- Nicholas C. Weaver nweaver at icsi.berkeley.edu This message has been ROT-13 encrypted twice for higher security. From nweaver at ICSI.Berkeley.EDU Fri Oct 5 07:21:21 2007 From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver) Date: Fri, 5 Oct 2007 07:21:21 -0700 Subject: [Bro] issue with geoip lookups In-Reply-To: <20071005142048.GA14697@kona.ICSI.Berkeley.EDU> References: <20071005135939.GA14612@kona.ICSI.Berkeley.EDU> <200710051419.l95EJ52U002732@pork.ICSI.Berkeley.EDU> <20071005142048.GA14697@kona.ICSI.Berkeley.EDU> Message-ID: <20071005142120.GB14697@kona.ICSI.Berkeley.EDU> Oh, wait. Yeah. Let me look into this a little more... On Fri, Oct 05, 2007 at 07:20:48AM -0700, Nicholas Weaver composed: > On Fri, Oct 05, 2007 at 07:19:00AM -0700, Vern Paxson composed: > > > This is just simply a print order, (City, region, country) rather than > > > (country, region, city), I believe. > > > > I believe he's referring to 64.236.22.63 instead returning information > > for 63.22.236.64 - which looks a lot like a missing ntohl(). > > Ah, yeah. (Didn't notice that). > > What is the function you are using to print the IP? > > -- > Nicholas C. Weaver nweaver at icsi.berkeley.edu > This message has been ROT-13 encrypted twice for higher security. -- Nicholas C. Weaver nweaver at icsi.berkeley.edu This message has been ROT-13 encrypted twice for higher security. From nweaver at ICSI.Berkeley.EDU Fri Oct 5 07:30:00 2007 From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver) Date: Fri, 5 Oct 2007 07:30:00 -0700 Subject: [Bro] issue with geoip lookups In-Reply-To: <20071005142048.GA14697@kona.ICSI.Berkeley.EDU> References: <20071005135939.GA14612@kona.ICSI.Berkeley.EDU> <200710051419.l95EJ52U002732@pork.ICSI.Berkeley.EDU> <20071005142048.GA14697@kona.ICSI.Berkeley.EDU> Message-ID: <20071005143000.GA14730@kona.ICSI.Berkeley.EDU> On Fri, Oct 05, 2007 at 07:20:48AM -0700, Nicholas Weaver composed: > On Fri, Oct 05, 2007 at 07:19:00AM -0700, Vern Paxson composed: > > > This is just simply a print order, (City, region, country) rather than > > > (country, region, city), I believe. > > > > I believe he's referring to 64.236.22.63 instead returning information > > for 63.22.236.64 - which looks a lot like a missing ntohl(). > > Ah, yeah. (Didn't notice that). > > What is the function you are using to print the IP? Runnning a test now. Sorry for the confusion on my part. -- Nicholas C. Weaver nweaver at icsi.berkeley.edu This message has been ROT-13 encrypted twice for higher security. From nweaver at ICSI.Berkeley.EDU Fri Oct 5 08:05:21 2007 From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver) Date: Fri, 5 Oct 2007 08:05:21 -0700 Subject: [Bro] issue with geoip lookups In-Reply-To: <20071005143000.GA14730@kona.ICSI.Berkeley.EDU> References: <20071005135939.GA14612@kona.ICSI.Berkeley.EDU> <200710051419.l95EJ52U002732@pork.ICSI.Berkeley.EDU> <20071005142048.GA14697@kona.ICSI.Berkeley.EDU> <20071005143000.GA14730@kona.ICSI.Berkeley.EDU> Message-ID: <20071005150521.GA14891@kona.ICSI.Berkeley.EDU> The test: nweaver at alpo:~/geoip/GeoIP-1.4.3/apps> ./geoiplookup 63.22.236.1 GeoIP City Edition, Rev 1: US, MA, Westford, 01886, 42.588799, -71.441597, 506, 978 GeoIP City Edition, Rev 0: US, MA, Westford, 01886, 42.588799, -71.441597 nweaver at alpo:~/geoip/GeoIP-1.4.3/apps> ./geoiplookup 1.236.22.63 GeoIP City Edition, Rev 1: IP Address not found GeoIP City Edition, Rev 0: IP Address not found nweaver at alpo:~/geoip/GeoIP-1.4.3/apps> Manually confirmed 63.22.236.1 is in the boston area by traceroute (last hop before failure is ar2.bos24.alter.net, and there is a huge hop in latency of 85ms between sjc*.alter.net and bos*.alter.net Using my geo-alert google-map policy, it IS the opposite: 1.236.22.63 is the one resolved. A change in bro.bif < gir = GeoIP_record_by_ipnum(geoip, addr); --- > gir = GeoIP_record_by_ipnum(geoip, ntohl(addr)); and it works right, thanks Vern. The GeoIP library's internal form is a.b.c.d -> a << 24 + b << 16 + c << 8 + d << 0 So standard host order, while Bro keeps while bro's AddrVal type is network order. -- Nicholas C. Weaver nweaver at icsi.berkeley.edu This message has been ROT-13 encrypted twice for higher security. From nweaver at ICSI.Berkeley.EDU Fri Oct 5 08:08:07 2007 From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver) Date: Fri, 5 Oct 2007 08:08:07 -0700 Subject: [Bro] issue with geoip lookups In-Reply-To: <20071005150521.GA14891@kona.ICSI.Berkeley.EDU> References: <20071005135939.GA14612@kona.ICSI.Berkeley.EDU> <200710051419.l95EJ52U002732@pork.ICSI.Berkeley.EDU> <20071005142048.GA14697@kona.ICSI.Berkeley.EDU> <20071005143000.GA14730@kona.ICSI.Berkeley.EDU> <20071005150521.GA14891@kona.ICSI.Berkeley.EDU> Message-ID: <20071005150807.GC25077@kona.ICSI.Berkeley.EDU> So Stephan, thanks again for the bug report. You can patch your own copy by making the change in src/bro.bif < gir = GeoIP_record_by_ipnum(geoip, addr); --- > gir = GeoIP_record_by_ipnum(geoip, ntohl(addr)); and recompiling. -- Nicholas C. Weaver nweaver at icsi.berkeley.edu This message has been ROT-13 encrypted twice for higher security. From ttenhune at nps.edu Fri Oct 5 09:53:00 2007 From: ttenhune at nps.edu (Tenhunen, Thomas (CIV)) Date: Fri, 5 Oct 2007 09:53:00 -0700 Subject: [Bro] (no subject) Message-ID: Hello Bro developers and users, I'm new to Bro but I'm thinking about using it in my thesis research. So far the installation of 1.3.2 and 1.2.1 has gone well. As a test I ran bro against trace1.tcpdump and buffer-overflow-attack.tcpdump which worked fine. Next I created a tcpdump file using tcpdump -w test.out. Tcpdump captured several packets. When bro is ran against this file it kicks out an error: command given: bro -r test.out tcp error returned: line 1: warning: event handlers never invoked: line 1: warning: account_tried Is there a trick to creating the tcpdump files? Running FreeBSD 6.2 with libpcap 0.97 Used root for all commands. $PATH is updated with /usr/local/bro/bin setenv BROPATH /usr/local/bro/policy:/usr/local/bro/site setenv BRO_DNS_FAKE 1 Any explanation you can share about this error would be great. Thanks. v/r Thomas Tenhunen Naval Postgraduate School Code 368-SFS ttenhune at nps.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071005/26eb0c03/attachment.html From nweaver at ICSI.Berkeley.EDU Fri Oct 5 10:22:07 2007 From: nweaver at ICSI.Berkeley.EDU (Nicholas Weaver) Date: Fri, 5 Oct 2007 10:22:07 -0700 Subject: [Bro] (no subject) In-Reply-To: References: Message-ID: <20071005172207.GA25911@kona.ICSI.Berkeley.EDU> On Fri, Oct 05, 2007 at 09:53:00AM -0700, Tenhunen, Thomas (CIV) composed: > > Hello Bro developers and users, > > I'm new to Bro but I'm thinking about using it in my thesis research. So far the installation of 1.3.2 and 1.2.1 has gone well. > > As a test I ran bro against trace1.tcpdump and buffer-overflow-attack.tcpdump which worked fine. Next I created a tcpdump file using tcpdump -w test.out. Tcpdump captured several packets. When bro is ran against this file it kicks out an error: Do tcpdump -w test.out -s 0 so it captures whole packets By default, tcpdump only grabs headers. -- Nicholas C. Weaver nweaver at icsi.berkeley.edu This message has been ROT-13 encrypted twice for higher security. From ssmit7 at gmail.com Fri Oct 5 10:43:52 2007 From: ssmit7 at gmail.com (Stephen Smith) Date: Fri, 5 Oct 2007 13:43:52 -0400 Subject: [Bro] issue with geoip lookups In-Reply-To: <20071005150807.GC25077@kona.ICSI.Berkeley.EDU> References: <20071005135939.GA14612@kona.ICSI.Berkeley.EDU> <200710051419.l95EJ52U002732@pork.ICSI.Berkeley.EDU> <20071005142048.GA14697@kona.ICSI.Berkeley.EDU> <20071005143000.GA14730@kona.ICSI.Berkeley.EDU> <20071005150521.GA14891@kona.ICSI.Berkeley.EDU> <20071005150807.GC25077@kona.ICSI.Berkeley.EDU> Message-ID: That does the job. Thanks for the quick responses. Stephen On 10/5/07, Nicholas Weaver wrote: > > So Stephan, thanks again for the bug report. > > You can patch your own copy by making the change in src/bro.bif > > < gir = GeoIP_record_by_ipnum(geoip, addr); > --- > > gir = GeoIP_record_by_ipnum(geoip, ntohl(addr)); > > and recompiling. > > > -- > Nicholas C. Weaver nweaver at icsi.berkeley.edu > This message has been ROT-13 encrypted twice for higher security. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071005/a0000442/attachment.html From robin at icir.org Fri Oct 5 11:10:03 2007 From: robin at icir.org (Robin Sommer) Date: Fri, 5 Oct 2007 11:10:03 -0700 Subject: [Bro] (no subject) In-Reply-To: References: Message-ID: <20071005181003.GB31821@icir.org> On Fri, Oct 05, 2007 at 09:53 -0700, Tenhunen, Thomas (CIV) wrote: > error returned: > > line 1: warning: event handlers never invoked: > line 1: warning: account_tried This is actually not an error but just a warning which you can typically ignore. See if Bro created any output in conn.log. Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From fabian at net.t-labs.tu-berlin.de Tue Oct 9 05:57:26 2007 From: fabian at net.t-labs.tu-berlin.de (Fabian Schneider) Date: Tue, 9 Oct 2007 14:57:26 +0200 (CEST) Subject: [Bro] Small bug in heavy.http.bro Message-ID: Hi, i just found another small bug. in heavy.http.bro: redef http_sessions &write_expire = 5 hours; it should be: redef http_sessions &write_expire = 5 hr; bye Fabian -- Fabian Schneider, An-Institut Deutsche Telekom Laboratories Technische Universit?t Berlin, Fakult?t IV -- Elektrotechnik und Informatik address: Sekr. TEL 4, FG INET, Ernst-Reuter-Platz 7, 10587 Berlin e-mail: fabian at net.t-labs.tu-berlin.de, WWW: http://www.net.in.tum.de/~schneifa phone: +49 30 8353 - 58513, mobile: +49 160 479 43 97 From r.gruyters at yirdis.nl Tue Oct 9 07:01:47 2007 From: r.gruyters at yirdis.nl (Robin Gruyters) Date: Tue, 9 Oct 2007 16:01:47 +0200 Subject: [Bro] Multi interfaces, one with and one without vlan tagging Message-ID: <20071009140147.GA87489@server.yirdis.net> Hi ya, I'm just wondering, what will be the best approch to filter vlan tags when I have Bro listening on two interfaces, which one needs to have a vlan filter and the other doesn't? If I enable "@load vlan" then Bro only monitors traffic on the interface which needs to have vlan filter. Here output from info logfile: pcap bufsize = 4194304 listening on sf5 pcap bufsize = 4194304 listening on sf7 Bro Version: 1.3.2 Started with the following command line options: -W -i sf5 -i sf7 monitor.bro Capture filter: (vlan) and (((((((((((port ftp) or (port smtp)) or (tcp[13] & 7 != 0)) or (port 111)) or (tcp src port 80 or tcp src port 8080 or tcp src port 8000)) or (port 6666)) or (port telnet or tcp port 513)) or ((ip[6:2] & 0x3fff != 0) and tcp)) or (udp port 69)) or (port 6667)) or (tcp dst port 80 or tcp dst port 8080 or tcp dst port 8000)) 1191794420.634934 received termination signal 949304 packets received on interface sf5, 0 dropped 0 packets received on interface sf7, 0 dropped As you can see, It hasn't received any packets from sf7. (sf7 = without vlan tagging) Kind regards, -- Robin Gruyters Network and Security Engineer YIRDIS - Betronic Services I: http://yirdis.com I: http://betronic.nl P: +31 (0)20 5659191 F: +31 (0)20 5659190 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071009/2dd7b6e7/attachment.bin From vern at icir.org Tue Oct 9 15:56:08 2007 From: vern at icir.org (Vern Paxson) Date: Tue, 09 Oct 2007 15:56:08 -0700 Subject: [Bro] inbound PortScans that aren't really... In-Reply-To: (Mon, 01 Oct 2007 16:13:18 CDT). Message-ID: <200710092256.l99MuD3D001599@pork.ICSI.Berkeley.EDU> > > Can you send me a trace of one of these scans? (Just TCP control > > packets is fine if there's content you can't pass on). > ... > We have a free copy of splunk indexing the /usr/local/bro/logs/* > files. Using splunk provides an easy way to retrieve data from all > of the BRO files - conn, notice, info, etc. Tim Rupp did this. He's > available for hire! > > I saw an outbound scan report today and used this splunk command ... To figure this out, we really need a raw trace. The reason is the appearance of a bunch of connections with state given as "OTH". Those reflect a non-standard connection establishment (often due to Bro missing the beginning of the connection, or multi-pathing, or the packet filter reordering SYNs with SYN ACKs), which are probably what's confusing the scan detector about the direction of the activity. You can anonymize a raw trace using ipsumdump -A. Alternatively, you could run Bro on it using "record_state_history=T" at the command line to turn on connection state history tracking, which would probably let us infer what's going on. Vern From rreitz at fnal.gov Wed Oct 10 08:53:04 2007 From: rreitz at fnal.gov (Randolph Reitz) Date: Wed, 10 Oct 2007 10:53:04 -0500 Subject: [Bro] Capturing the raw trace... Message-ID: <11305779-A8E8-451F-AEBA-A6234581603C@fnal.gov> OK, so I understand that to really debug BRO one needs tcpdump stuff rather than BRO's connection records. Discussing how to get a continuous supply of tcpdump stuff, Tim Rupp and I have come up this this idea ... -------------- next part -------------- A non-text attachment was scrubbed... Name: picture.jpg Type: image/jpeg Size: 18751 bytes Desc: not available Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071010/f8cd8231/attachment-0001.jpg -------------- next part -------------- Before we go off and invent the above, I'm asking if this already exists? Does BRO have some secret way of preserving the libpcap output (er, the BRO input)? Thanks, Randy From robin at icir.org Wed Oct 10 10:12:49 2007 From: robin at icir.org (Robin Sommer) Date: Wed, 10 Oct 2007 10:12:49 -0700 Subject: [Bro] Capturing the raw trace... In-Reply-To: <11305779-A8E8-451F-AEBA-A6234581603C@fnal.gov> References: <11305779-A8E8-451F-AEBA-A6234581603C@fnal.gov> Message-ID: <20071010171249.GA13609@icir.org> On Wed, Oct 10, 2007 at 10:53 -0500, Randolph Reitz wrote: > exists? Does BRO have some secret way of preserving the libpcap > output (er, the BRO input)? Nice picture. :) But try the -w option first; it records all of Bro's input into a trace file. Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From rreitz at fnal.gov Wed Oct 10 11:27:27 2007 From: rreitz at fnal.gov (Randolph Reitz) Date: Wed, 10 Oct 2007 13:27:27 -0500 Subject: [Bro] Capturing the raw trace... In-Reply-To: <20071010171249.GA13609@icir.org> References: <11305779-A8E8-451F-AEBA-A6234581603C@fnal.gov> <20071010171249.GA13609@icir.org> Message-ID: <080F4C55-38B0-467D-B4F3-AEC2245E4FEB@fnal.gov> Doh! RTFM! I actually spent some time *reading* the tcpdump man page (on tcpdump.org) and discovered that the '-G 3600' option will rotate the -w log files every hour. Humm, my Linux tcpdump 3.8 doesn't seem to have a -G option. Looks like I need tcpdump 3.9? I will run tcpdump on a different system from BRO. I happen to have two systems connected to the border traffic fire-hose. I will be able to wait for BRO to trigger on a bogus outbound port scan and then go look for the raw dump file. So far, BRO hasn't triggered on any bogus outbound port scans since I sent my original mail. Humm, this must be a Heisenbug. Thanks, Randy On Oct 10, 2007, at 12:12, Robin Sommer wrote: > > On Wed, Oct 10, 2007 at 10:53 -0500, Randolph Reitz wrote: > >> exists? Does BRO have some secret way of preserving the libpcap >> output (er, the BRO input)? > > Nice picture. :) But try the -w option first; it records all of > Bro's input into a trace file. Well, we need to manage the trace file. When BRO is checkpointed daily, will a new trace file be created? > > Robin > > -- > Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org > ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro From rreitz at fnal.gov Wed Oct 10 11:49:35 2007 From: rreitz at fnal.gov (Randolph Reitz) Date: Wed, 10 Oct 2007 13:49:35 -0500 Subject: [Bro] tcpdump -G option seems missing Message-ID: <8C562600-6746-4102-A764-14F077D1784B@fnal.gov> Looking at http://www.tcpdump.org/tcpdump_man.html, I became excited over the '-G rotate_seconds' option. Having retrieved and built the latest tcpdump ... [rreitz at babar tcpdump-3.9.8]$ /usr/local/sbin/tcpdump -G tcpdump version 3.9.8 libpcap version 0.8.3 Usage: tcpdump [-aAdDeflLnNOpqRStuUvxX] [-c count] [ -C file_size ] [ -E algo:secret ] [ -F file ] [ -i interface ] [ -M secret ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [ -W filecount ] [ -y datalinktype ] [ -Z user ] [ expression ] I don't have any -G option. Does anyone on this list know where the - G option is kept? Thanks, Randy From budong at info-pull.com Wed Oct 10 12:21:54 2007 From: budong at info-pull.com (Brute Dong) Date: Wed, 10 Oct 2007 12:21:54 -0700 Subject: [Bro] tcpdump -G option seems missing In-Reply-To: <8C562600-6746-4102-A764-14F077D1784B@fnal.gov> References: <8C562600-6746-4102-A764-14F077D1784B@fnal.gov> Message-ID: i just looked at the source code and it seems that the -G option is no longer there. the tcpdump man page you read is from 2005, so it seems that they havev may removed it. On 10/10/07, Randolph Reitz wrote: > > Looking at http://www.tcpdump.org/tcpdump_man.html, I became excited > over the '-G rotate_seconds' option. Having retrieved and built the > latest tcpdump ... > > [rreitz at babar tcpdump-3.9.8]$ /usr/local/sbin/tcpdump -G > tcpdump version 3.9.8 > libpcap version 0.8.3 > Usage: tcpdump [-aAdDeflLnNOpqRStuUvxX] [-c count] [ -C file_size ] > [ -E algo:secret ] [ -F file ] [ -i interface ] [ -M > secret ] > [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] > [ -W filecount ] [ -y datalinktype ] [ -Z user ] > [ expression ] > > I don't have any -G option. Does anyone on this list know where the - > G option is kept? > > Thanks, > Randy > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071010/0915d911/attachment.html From robin at icir.org Wed Oct 10 12:22:52 2007 From: robin at icir.org (Robin Sommer) Date: Wed, 10 Oct 2007 12:22:52 -0700 Subject: [Bro] Capturing the raw trace... In-Reply-To: <080F4C55-38B0-467D-B4F3-AEC2245E4FEB@fnal.gov> References: <11305779-A8E8-451F-AEBA-A6234581603C@fnal.gov> <20071010171249.GA13609@icir.org> <080F4C55-38B0-467D-B4F3-AEC2245E4FEB@fnal.gov> Message-ID: <20071010192252.GA16756@icir.org> On Wed, Oct 10, 2007 at 13:27 -0500, you wrote: > the -w log files every hour. Humm, my Linux tcpdump 3.8 doesn't seem > to have a -G option. Looks like I need tcpdump 3.9? (Yes, I think it's a pretty recent addition.) Running a tcpdump in parallel is certainly a good thing if you have the resources for that. > Well, we need to manage the trace file. When BRO is checkpointed > daily, will a new trace file be created? You can use the mechanisms in rotate-logs.bro to rotate the trace file with all the other logs by adding it to the aux_files set. (When Bro rotates the files in aux_files, it will automagically do the right pcap magic for the trace file.) Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From tarupp at fnal.gov Wed Oct 10 12:13:53 2007 From: tarupp at fnal.gov (Tim Rupp) Date: Wed, 10 Oct 2007 14:13:53 -0500 Subject: [Bro] Capturing the raw trace... In-Reply-To: <11305779-A8E8-451F-AEBA-A6234581603C@fnal.gov> References: <11305779-A8E8-451F-AEBA-A6234581603C@fnal.gov> Message-ID: <470D2471.8010103@fnal.gov> Found it in tcpdump. Looks like it's not in the recent stable tarballs though; I needed to compile from CVS. Use the -G flag with an appropriate -w flag for example, to create a new dump file every 10 seconds: tcpdump -G 10 -i eth0 -w "%Y-%m-%d_%H:%M:%S" will create files that look like 2007-10-10_14:10:14 2007-10-10_14:10:24 2007-10-10_14:10:34 2007-10-10_14:10:44 2007-10-10_14:10:54 Note that the time interval to -G isn't 100% accurate, but it's close enough. So LBL needs to push out 3.9 so that the world can rejoice in -G : ) Thanks, -Tim Randolph Reitz wrote: > OK, so I understand that to really debug BRO one needs tcpdump stuff > rather than BRO's connection records. > > Discussing how to get a continuous supply of tcpdump stuff, Tim Rupp and > I have come up this this idea ... > > > ------------------------------------------------------------------------ > > Before we go off and invent the above, I'm asking if this already > exists? Does BRO have some secret way of preserving the libpcap output > (er, the BRO input)? > > Thanks, > Randy > From d.nechay at gmail.com Wed Oct 10 12:40:37 2007 From: d.nechay at gmail.com (Danny Nechay) Date: Wed, 10 Oct 2007 15:40:37 -0400 Subject: [Bro] Flow Statistics in BRO Message-ID: Hi, I have a trace file (from using TCPdump) and I would like to know how to get the flow statistics of this file using BRO (i.e. what would be the command line argument). Thanks. DAN -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071010/2a926437/attachment.html From mcuttler at bnl.gov Wed Oct 10 13:07:05 2007 From: mcuttler at bnl.gov (Matt Cuttler) Date: Wed, 10 Oct 2007 16:07:05 -0400 Subject: [Bro] Capturing the raw trace... In-Reply-To: <11305779-A8E8-451F-AEBA-A6234581603C@fnal.gov> References: <11305779-A8E8-451F-AEBA-A6234581603C@fnal.gov> Message-ID: <470D30E9.5060701@bnl.gov> Randolph Reitz wrote: > OK, so I understand that to really debug BRO one needs tcpdump stuff > rather than BRO's connection records. > > Discussing how to get a continuous supply of tcpdump stuff, Tim Rupp > and I have come up this this idea ... > > > Before we go off and invent the above, I'm asking if this already > exists? Does BRO have some secret way of preserving the libpcap > output (er, the BRO input)? > > Thanks, > Randy > If you're looking to write pcaps out to disk, you can use something like Time Machine (1), or Daemonlogger (2) 1: http://www.net.t-labs.tu-berlin.de/research/tm/ 2: http://www.snort.org/users/roesch/Site/Daemonlogger.html If you're interested, we can discuss off-list :) -Matt Cuttler From robin at icir.org Wed Oct 10 13:58:05 2007 From: robin at icir.org (Robin Sommer) Date: Wed, 10 Oct 2007 13:58:05 -0700 Subject: [Bro] Flow Statistics in BRO In-Reply-To: References: Message-ID: <20071010205805.GB18544@icir.org> On Wed, Oct 10, 2007 at 15:40 -0400, Danny Nechay wrote: > I have a trace file (from using TCPdump) and I would like to know how to get > the flow statistics of this file using BRO (i.e. what would be the command > line argument). "bro -r trace tcp" should do it if you're only concerned about TCP. For UDP and ICMP add "udp" and "icmp" to the command line, respectively. Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From vern at icir.org Wed Oct 10 14:37:48 2007 From: vern at icir.org (Vern Paxson) Date: Wed, 10 Oct 2007 14:37:48 -0700 Subject: [Bro] Capturing the raw trace... In-Reply-To: <470D2471.8010103@fnal.gov> (Wed, 10 Oct 2007 14:13:53 CDT). Message-ID: <200710102137.l9ALbr5P000824@pork.ICSI.Berkeley.EDU> > So LBL needs to push out 3.9 so that the world can rejoice in -G : ) FYI, LBL is no longer in the tcpdump development business. That's done by folks at tcpdump.org, and has been for a while. Vern From d.nechay at gmail.com Wed Oct 10 14:39:46 2007 From: d.nechay at gmail.com (Danny Nechay) Date: Wed, 10 Oct 2007 17:39:46 -0400 Subject: [Bro] Fwd: Flow Statistics in BRO In-Reply-To: References: <20071010205805.GB18544@icir.org> Message-ID: Hi, when I run that command I get the following output (a sample): 1185209476.627097 weird: spontaneous_RST 1185209476.630111 weird: spontaneous_RST 1185209476.947233 weird: above_hole_data_without_any_acks 1185209478.283928 weird: spontaneous_FIN 1185209478.798191 weird: above_hole_data_without_any_acks 1185209479.339797 weird: spontaneous_RST 1185209479.943993 weird: spontaneous_RST 1185209480.904227 weird: spontaneous_FIN 1185209481.648424 weird: above_hole_data_without_any_acks When I was talking about flow statistics, I was looking more for statistics such as total number of packets, average packet size, total bytes, total header (transport plus network layer) bytes, number of caller to callee packets, total caller to callee bytes, total caller to callee payload bytes, total caller to callee header bytes, number of callee to caller packets, total callee to caller payload bytes, and total callee to caller header bytes. Also as an aside, do you know why there are these weird addresses in the scan.bro file because whenever I run bro -r tracefile tcp it always starts with the following lines: /usr/local/bro/policy/scan.bro, line 92: warning: no such host: j5004.inktomisearch.com /usr/local/bro/policy/scan.bro, line 92: warning: no such host: j5005.inktomisearch.com /usr/local/bro/policy/scan.bro, line 93: warning: no such host: j5006.inktomisearch.com /usr/local/bro/policy/scan.bro, line 93: warning: no such host: j100.inktomi.com /usr/local/bro/policy/scan.bro, line 93: warning: no such host: j101.inktomi.com /usr/local/bro/policy/scan.bro, line 94: warning: no such host: j3002.inktomi.com /usr/local/bro/policy/scan.bro, line 94: warning: no such host: si3000.inktomi.com /usr/local/bro/policy/scan.bro, line 94: warning: no such host: si3001.inktomi.com /usr/local/bro/policy/scan.bro, line 95: warning: no such host: si3002.inktomi.com /usr/local/bro/policy/scan.bro, line 95: warning: no such host: si3003.inktomi.com /usr/local/bro/policy/scan.bro, line 95: warning: no such host: si4000.inktomi.com /usr/local/bro/policy/scan.bro, line 96: warning: no such host: si4001.inktomi.com /usr/local/bro/policy/scan.bro, line 96: warning: no such host: si4002.inktomi.com /usr/local/bro/policy/scan.bro, line 96: warning: no such host: wm3018.inktomi.com line 1: warning: event handlers never invoked: line 1: warning: account_tried Thanks. Daniel. On 10/10/07, Robin Sommer wrote: > > > On Wed, Oct 10, 2007 at 15:40 -0400, Danny Nechay wrote: > > > I have a trace file (from using TCPdump) and I would like to know how to > get > > the flow statistics of this file using BRO (i.e. what would be the > command > > line argument). > > "bro -r trace tcp" should do it if you're only concerned about TCP. > For UDP and ICMP add "udp" and "icmp" to the command line, > respectively. > > Robin > > -- > Robin Sommer * Phone +1 (510) 931-5555 * 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/20071010/08aa7b6f/attachment-0001.html From ml at grid.einherjar.de Wed Oct 10 16:52:38 2007 From: ml at grid.einherjar.de (Thorolf) Date: Wed, 10 Oct 2007 23:52:38 +0000 Subject: [Bro] SMTP Analyzer Message-ID: <470D65C6.4060703@grid.einherjar.de> Hello all, since few weeks I'm watching bruteforce attacks on SMTP AUTH. It does looks like this: 2007-08-28 22:00:33 plain_login authenticator failed for (ameill-2007) [222.183.149.252]: 535 Incorrect authentication data (set_id=company) 2007-09-30 07:41:11 plain_login authenticator failed for (ameill-2007) [222.183.160.28]: 535 Incorrect authentication data (set_id=administrator) 2007-09-30 21:26:16 plain_login authenticator failed for (windows) [64.72.227.37]: 535 Incorrect authentication data (set_id="null") Affected box is running exim (just as info). I would like to make bro recognize such attacks, so could someone be so kind and give me some hints where to strart? I have checked out src/SMTP.cc, policy/smtp.bro but it is kind weird. First problem I can't solve "ad hoc" is: 1192050353.634741 #136 xx.xx.33.62/20241 > xx.xx.xx.44/smtp start external 1192050395.930749 #136 error: command mismatch: **(4) [cmd=**, cmd_arg=IQ==, reply=0, reply_arg=, cont_reply=F, log_reply=F](4), AUTH_ANSWER (334 UGFzc3dvcmQ6) 1192050397.092847 #136 error: command mismatch: **(5) [cmd=**, cmd_arg=, reply=0, reply_arg=, cont_reply=F, log_reply=F](5), AUTH_ANSWER (235 Authentication succeeded) 1192050399.164633 #136 finish session does look like this: >> my input << server response SMTP>> EHLO test.pl SMTP<< 250 banner SMTP>> AUTH LOGIN SMTP<< 334 VXNlcm5hbWU6 SMTP>> IQ== SMTP<< 334 UGFzc3dvcmQ6 SMTP>> SMTP<< 235 Authentication succeeded so commands are in good sequence yet bro does tell me that it is wrong. Where should I start with fixing, I'm familiar with bro language, have wrote many other policies from scratch for our company, but I'm a little bit confused where to start with SMTP. thx and kind regards, Rafal From gregor at net.t-labs.tu-berlin.de Wed Oct 10 15:39:26 2007 From: gregor at net.t-labs.tu-berlin.de (Gregor Maier) Date: Thu, 11 Oct 2007 00:39:26 +0200 Subject: [Bro] Fwd: Flow Statistics in BRO In-Reply-To: References: <20071010205805.GB18544@icir.org> Message-ID: <470D549E.5010907@net.t-labs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Danny Nechay wrote: > When I was talking about flow statistics, I was looking more for > statistics such as total number of packets, average packet size, total > bytes, total header (transport plus network layer) bytes, number of > caller to callee packets, total caller > to callee bytes, total caller to callee payload bytes, total caller to > callee header bytes, number of callee to > caller packets, total callee to caller payload bytes, and total callee > to caller header bytes. You can use the one-line connection summaries from bro: bro -r trace conn This won't give you all the information you're interested in, but it's a starting point. hth gregor - -- Gregor Maier gregor at net.t-labs.tu-berlin.de TU Berlin / Deutsche Telekom Labs gregor.maier at tu-berlin.de Sekr. TEL 4, FG INET www.net.t-labs.tu-berlin.de Ernst-Reuter-Platz 7 10587 Berlin, Germany -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHDVSedGiwgbikMYMRAisHAKCmnoIvUS9Sgvr3KTRFNJFe1vZQ8QCfQV5C OmsAhXz9dDysH5MoGa6QNuE= =LXYS -----END PGP SIGNATURE----- From geek00l at gmail.com Wed Oct 10 17:34:30 2007 From: geek00l at gmail.com (CS Lee) Date: Thu, 11 Oct 2007 08:34:30 +0800 Subject: [Bro] Flow statistic Message-ID: <1bb5dd90710101734p7e640d89w915584adaa0719c3@mail.gmail.com> Hi there, Regarding flow statistic, you can do - bro -r whatever.pcap tcp udp icmp conn It will generate the connection summaries for you which is pretty close to what flow means. If you want to generate further statistic, you can use ipsumdump + ipaggcreate. Or if you are looking for something exactly like you have mentioned, take a look at argus - http://qosient.com/argus Sometimes we really need right tool for the right job. -- Best Regards, CS Lee http://geek00l.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071011/4bab264b/attachment.html From geek00l at gmail.com Wed Oct 10 17:41:00 2007 From: geek00l at gmail.com (CS Lee) Date: Thu, 11 Oct 2007 08:41:00 +0800 Subject: [Bro] Bro Digest, Vol 18, Issue 8 In-Reply-To: References: Message-ID: <1bb5dd90710101741t4f9b5204ubaaabaea079f311e@mail.gmail.com> Randy, Maybe this is easy way to get raw trace - http://geek00l.blogspot.com/2006/12/bro-ids-enable-full-content-data.html If you are really looking at ring buffer, daemonlogger will do. If you are encountering any issue with bro in certain timeline and say you want to extract the data from that period, you can do the job with tcpslice. Cheers ;] -- Best Regards, CS Lee http://geek00l.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071011/1f73e2cb/attachment.html From robin at icir.org Wed Oct 10 21:02:46 2007 From: robin at icir.org (Robin Sommer) Date: Wed, 10 Oct 2007 21:02:46 -0700 Subject: [Bro] Fwd: Flow Statistics in BRO In-Reply-To: References: <20071010205805.GB18544@icir.org> Message-ID: <20071011040246.GA20484@icir.org> (Got this mail in private first; here's a copy of my reply to the list.) On Wed, Oct 10, 2007 at 17:38 -0400, you wrote: > 1185209481.648424 weird: above_hole_data_without_any_acks You can actually just ignore these messages, or load weird.bro which sends them to weird.log. > When I was talking about flow statistics, I was looking more for statistics > such as total number of packets, average packet size, total bytes, total > header Have you looked into conn.log? Bro doesn't count packets per flow but the rest of the information you're looking for should be in there. (If I understand you correctly that you want *per-flow* statistics and not an overall summary of, e.g., bytes in the trace). > Also as an aside, do you know why there are these weird addresses in the > scan.bro file because whenever I run bro -r tracefile tcp it always starts > with the following lines: They are an relict from the past when these hosts still existed, to suppress reporting them as scanners. You can simply remove them from the scan.bro to get rid the warning. Iirc this has alreaby been done in the current development version. Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From vern at icir.org Wed Oct 10 21:12:16 2007 From: vern at icir.org (Vern Paxson) Date: Wed, 10 Oct 2007 21:12:16 -0700 Subject: [Bro] Fwd: Flow Statistics in BRO In-Reply-To: (Wed, 10 Oct 2007 17:39:46 EDT). Message-ID: <200710110412.l9B4CLGD007016@pork.ICSI.Berkeley.EDU> > Also as an aside, do you know why there are these weird addresses in the > scan.bro file because whenever I run bro -r tracefile tcp it always starts > with the following lines: > > /usr/local/bro/policy/scan.bro, line 92: warning: no such host: > j5004.inktomisearch.com These are historical (they used to actually make good examples!, but those hosts have now gone away). They were recently removed, however - are you using the CURRENT release? Vern From ager at net.in.tum.de Thu Oct 11 06:03:32 2007 From: ager at net.in.tum.de (Bernhard Ager) Date: Thu, 11 Oct 2007 15:03:32 +0200 Subject: [Bro] How to count concurrent connections Message-ID: <20071011130331.GL25225@in.tum.de> Hi, I am currently trying to count concurrent connections. I'd like to use a script like this: redef ignore_checksums = T; redef capture_filters += { ["tcp-setup"] = "tcp" }; global conncounter_file = open_log_file ("conncounter"); global total_conn_count = 0; global concurrent_conn_count = 0; event connection_established (c: connection) { ++total_conn_count; ++concurrent_conn_count; if (total_conn_count % 1000 == 0) { print conncounter_file, fmt ("%.06f total: %08d max concurrent: %d", network_time(), total_conn_count, concurrent_conn_count); } } event connection_state_removed (c: connection) { --concurrent_conn_count; } However, the numbers I get soon become negative resp. I get a runtime error - counter negative. A quick check showed me that connection_state_removed gets thrown up to four times per connection in only the first few minutes of my trace. I then tried to replace connection_state_removed() with connection_reset() and connection_finished(). However I am not convinced this is enough because even after more then 90 minutes trace time concurrent_conn_count is still increasing significantly (~1300 per minute on a 1 Gig uplink). So my question now is: which events are thrown when exactly? Do I have to track the established connections in the scripting layer? Is there a way to just query for the size of the bro-internal connection tracker? BTW: I am using a header trace. In my opinion this shouldn't make a difference, but maybe ... Thanks for help! Bernhard -- Technische Universit?t Berlin An-Institut Deutsche Telekom Laboratories FG INET, Research Group Anja Feldmann Sekr. TEL 4 Ernst-Reuter-Platz 7 D-10587 Berlin From christian at whoop.org Thu Oct 11 10:21:47 2007 From: christian at whoop.org (Christian Kreibich) Date: Thu, 11 Oct 2007 10:21:47 -0700 Subject: [Bro] tcpdump -G option seems missing In-Reply-To: References: <8C562600-6746-4102-A764-14F077D1784B@fnal.gov> Message-ID: <1192123307.21421.111.camel@strangepork> On Wed, 2007-10-10 at 12:21 -0700, Brute Dong wrote: > i just looked at the source code and it seems that the -G option is no > longer there. the tcpdump man page you read is from 2005, so it seems > that they havev may removed it. I'm not sure whether -G was ever officially accepted. You can however find a patch and some related discussion here: https://sourceforge.net/tracker/index.php?func=detail&aid=1066046&group_id=53066&atid=469575 Note that if you're happy to move forward your conveyor belt whenever a bucket is full, there's also -C. Cheers, Christian -- ________________________________________________________________________ http://www.icir.org/christian http://www.whoop.org From robin at icir.org Thu Oct 11 10:45:53 2007 From: robin at icir.org (Robin Sommer) Date: Thu, 11 Oct 2007 10:45:53 -0700 Subject: [Bro] How to count concurrent connections In-Reply-To: <20071011130331.GL25225@in.tum.de> References: <20071011130331.GL25225@in.tum.de> Message-ID: <20071011174553.GA24159@icir.org> On Thu, Oct 11, 2007 at 15:03 +0200, Bernhard Ager wrote: > So my question now is: which events are thrown when exactly? The event you're looking for is new_connection(). That one is raised for all connections for which Bro instantiates internal state, i.e., it's the counterpart of connection_state_remove(). The other connection events are only raised for a subset of all connections. connection_established() for those with a full 3w handshake, connection_finished() for regular tear-downs, connection_reset() for connection aborted with a reset, etc. > Is there > a way to just query for the size of the bro-internal connection > tracker? Actually there is: the built-in resource_usage() returns a record which, among other stuff, contains the numbers of TCP, UDP, ICMP connections in memory. Caveat: I'm just realizing that this reporting doesn't take the connection-compressor into account, which means that by default the values will be too small for TCP connections. Turning off the compressor with use_connection_compressor=F will fix that for the cost of some performance decrease (both cpu and memory). > BTW: I am using a header trace. In my opinion this shouldn't make a > difference, but maybe ... No, it shouldn't. Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From vern at icir.org Thu Oct 11 11:59:47 2007 From: vern at icir.org (Vern Paxson) Date: Thu, 11 Oct 2007 11:59:47 -0700 Subject: [Bro] nfs analysis In-Reply-To: <7f3e32390709241039m197f30d4r2378bc715d194c7a@mail.gmail.com> (Mon, 24 Sep 2007 10:39:20 PDT). Message-ID: <200710111859.l9BIxqQH024608@pork.ICSI.Berkeley.EDU> Sorry for the delay on following up on this. > 16:01:13.467628 IP client.host.name.4160508447 > server.host.name.nfs: > 132 getattr [|nfs] Whenever tcpdump displays "|xxx", it means that the packet was truncated due to a snapshot limitation. Bro can't analyze such packets at the application level. So you need to capture traffic using tcpdump -s 0 to turn off the limited snapshot. Note, the funky port number its showing is the NFS file handle (or maybe it's the RPC transaction ID - I forget which) - a tcpdump feature. So I'm not sure what to make about your later comment that this was a tcpdump bug ... > 1190415715.190522 weird: bad_RPC > 1190415715.190781 weird: unpaired_RPC_response These arise because Bro can't fully parse the RPC. Vern From vern at icir.org Thu Oct 11 12:02:43 2007 From: vern at icir.org (Vern Paxson) Date: Thu, 11 Oct 2007 12:02:43 -0700 Subject: [Bro] Multi interfaces, one with and one without vlan tagging In-Reply-To: <20071009140147.GA87489@server.yirdis.net> (Tue, 09 Oct 2007 16:01:47 +0200). Message-ID: <200710111902.l9BJ2mM8024703@pork.ICSI.Berkeley.EDU> > I'm just wondering, what will be the best approch to filter vlan tags when I > have Bro listening on two interfaces, which one needs to have a vlan > filter and the other doesn't? Unfortunately you will have to modify Bro's internals to do that. This is a general problem: when monitoring multiple interfaces, Bro currently is structured to assume that they're all using the same link layer. Vern From rporada at ll.mit.edu Thu Oct 11 12:47:07 2007 From: rporada at ll.mit.edu (Reed Porada) Date: Thu, 11 Oct 2007 15:47:07 -0400 Subject: [Bro] http-body and binary content Message-ID: <81504677-FB9D-4610-9173-EBED11322F43@ll.mit.edu> I want to reassemble the http-content for various streams. Right now I have been able to generically reassembled all of the content, but with mixed results. The plaintext content seems to be reassembling fine, however, binary content has had mixed results. I have successfully reassembled several gifs (minus a newline), but others I have not. Looking at the hexdump of the content output, it seems like some gifs are being outputed in ASCII Hex, and others real binary. I then looked at the packet captures, and ethereal is showing the binary of the gifs. The subtle difference that I have noticed is that the successful gifs do not have any "X-..." optional headers in them, whereas those that are failing have had "X-Cache" and "X-Pad" for example. Any thoughts on why Bro changes its output based on the optional headers? Or why it could be sometimes outputting binary and others ASCII Hex? Thanks, -Reed From vern at icir.org Thu Oct 11 18:01:19 2007 From: vern at icir.org (Vern Paxson) Date: Thu, 11 Oct 2007 18:01:19 -0700 Subject: [Bro] SMTP Analyzer In-Reply-To: <470D65C6.4060703@grid.einherjar.de> (Wed, 10 Oct 2007 23:52:38 -0000). Message-ID: <200710120101.l9C11OTk030787@pork.ICSI.Berkeley.EDU> > since few weeks I'm watching bruteforce attacks on SMTP AUTH. Could you send a trace of one of these attacks? That would be the easiest way for us to figure out whether the necessary events are already available, or if the event engine would need any extension to handle this. Vern From vern at icir.org Thu Oct 11 20:38:30 2007 From: vern at icir.org (Vern Paxson) Date: Thu, 11 Oct 2007 20:38:30 -0700 Subject: [Bro] http-body and binary content In-Reply-To: <81504677-FB9D-4610-9173-EBED11322F43@ll.mit.edu> (Thu, 11 Oct 2007 15:47:07 EDT). Message-ID: <200710120338.l9C3cZuK000734@pork.ICSI.Berkeley.EDU> > Any thoughts on why Bro changes its output based on the optional > headers? This almost for sure isn't the problem, as I don't believe there's any code relating to looking at the headers in this regard. > Or why it could be sometimes outputting binary and others > ASCII Hex? How are you using/printing the values recovered by Bro? Best bet is that you're running into Bro introducing some escape sequences. Vern From rporada at ll.mit.edu Fri Oct 12 06:59:07 2007 From: rporada at ll.mit.edu (Reed Porada) Date: Fri, 12 Oct 2007 09:59:07 -0400 Subject: [Bro] http-body and binary content In-Reply-To: <200710120338.l9C3cZuK000734@pork.ICSI.Berkeley.EDU> References: <200710120338.l9C3cZuK000734@pork.ICSI.Berkeley.EDU> Message-ID: On Oct 11, 2007, at 11:38 PM, Vern Paxson wrote: >> Any thoughts on why Bro changes its output based on the optional >> headers? > > This almost for sure isn't the problem, as I don't believe there's any > code relating to looking at the headers in this regard. I kinda figured that, but just wanted to make sure. >> Or why it could be sometimes outputting binary and others >> ASCII Hex? > > How are you using/printing the values recovered by Bro? Best bet > is that > you're running into Bro introducing some escape sequences. > I am storing the values as strings and printing to an open file. I was concatenating the data using the fmt() command. Given what you said, I switched to the cat () function and that works. Thanks for making me think about it more. The only thing I am still noticing is that with a print it appends a newline to each print statement. Is there anyway to prevent this? Thanks again, -Reed From ager at net.in.tum.de Fri Oct 12 08:34:02 2007 From: ager at net.in.tum.de (Bernhard Ager) Date: Fri, 12 Oct 2007 17:34:02 +0200 Subject: [Bro] How to count concurrent connections In-Reply-To: <20071011174553.GA24159@icir.org> References: <20071011130331.GL25225@in.tum.de> <20071011174553.GA24159@icir.org> Message-ID: <20071012153400.GQ25225@in.tum.de> On Thu, Oct 11, 2007 at 10:45:53AM -0700, Robin Sommer wrote: > The event you're looking for is new_connection(). That one is raised > for all connections for which Bro instantiates internal state, i.e., > it's the counterpart of connection_state_remove(). No, it is not :-) I only want fully established tcp connections. I tried out new_connection() however, and it gives me about 8 times more connections than there are fully-established tcp-connections (450k vs. 60k). By the way, I got my numbers now by using connection_established() to detect new connections, connection_state_remove() for decreasing the counter and a set of conn_id to ensure that a connection is removed only once. The price - of course - is the memory consumption of the extra table. > Actually there is: the built-in resource_usage() returns a record > which, among other stuff, contains the numbers of TCP, UDP, ICMP > connections in memory. I tried out the built-in resource_usage() as well, it gives pretty much the same results as the new_connection() approach: 1184669769.879156 total: 00116000 concurrent: 63310 max_TCP_conns: 63311 num_TCP_conns: 63310 1184669770.121984 total: 00117000 concurrent: 63796 max_TCP_conns: 63797 num_TCP_conns: 63796 1184669770.398366 total: 00118000 concurrent: 64256 max_TCP_conns: 64256 num_TCP_conns: 64256 However, sometimes, odd things happen. Like here, where resource_usage()$max_TCP_conns almost doubles for a short period of time (this is still in the startup phase): 1184669770.658614 total: 00119000 concurrent: 64683 max_TCP_conns: 64684 num_TCP_conns: 64683 1184669770.969641 total: 00120000 concurrent: 65106 max_TCP_conns: 73977 num_TCP_conns: 65106 1184669771.274491 total: 00121000 concurrent: 65511 max_TCP_conns: 83514 num_TCP_conns: 65511 1184669771.570219 total: 00122000 concurrent: 65973 max_TCP_conns: 93163 num_TCP_conns: 65973 1184669771.870853 total: 00123000 concurrent: 66452 max_TCP_conns: 102929 num_TCP_conns: 66452 1184669772.109635 total: 00124000 concurrent: 66873 max_TCP_conns: 112785 num_TCP_conns: 66873 1184669772.382840 total: 00125000 concurrent: 67299 max_TCP_conns: 122752 num_TCP_conns: 67299 1184669772.672518 total: 00126000 concurrent: 67767 max_TCP_conns: 67768 num_TCP_conns: 67767 After looking into the code this seems to happen exactly when the underlying PDict object does a table resize. Bye, Bernhard -- Technische Universit?t Berlin An-Institut Deutsche Telekom Laboratories FG INET, Research Group Anja Feldmann Sekr. TEL 4 Ernst-Reuter-Platz 7 D-10587 Berlin From robin at icir.org Sun Oct 14 16:54:17 2007 From: robin at icir.org (Robin Sommer) Date: Sun, 14 Oct 2007 16:54:17 -0700 Subject: [Bro] How to count concurrent connections In-Reply-To: <20071012153400.GQ25225@in.tum.de> References: <20071011130331.GL25225@in.tum.de> <20071011174553.GA24159@icir.org> <20071012153400.GQ25225@in.tum.de> Message-ID: <20071014235417.GA14099@icir.org> On Fri, Oct 12, 2007 at 17:34 +0200, Bernhard Ager wrote: > No, it is not :-) I only want fully established tcp connections. I (Ok, sorry, I misunderstood you and thought that you do want to count all connections.) > connection_established() to detect new connections, > connection_state_remove() for decreasing the counter and a set of > conn_id to ensure that a connection is removed only once. Yeah, that's actually the best approach then. > I tried out the built-in resource_usage() as well, it gives pretty > much the same results as the new_connection() approach: Right, that makes sense because it also counts all currently active connection independent of their state. > 1184669772.382840 total: 00125000 concurrent: 67299 max_TCP_conns: 122752 num_TCP_conns: 67299 > 1184669772.672518 total: 00126000 concurrent: 67767 max_TCP_conns: 67768 num_TCP_conns: 67767 > > After looking into the code this seems to happen exactly when the > underlying PDict object does a table resize. Yepp, that looks indeed like a bug in the accounting code. While the resize is on its way, there are actually two tables kept internally and it seems the code calculates the max size wrong during this time. Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From robin at icir.org Sun Oct 14 17:05:03 2007 From: robin at icir.org (Robin Sommer) Date: Sun, 14 Oct 2007 17:05:03 -0700 Subject: [Bro] Small bug in heavy.http.bro In-Reply-To: References: Message-ID: <20071015000502.GD14099@icir.org> On Tue, Oct 09, 2007 at 14:57 +0200, Fabian Schneider wrote: > i just found another small bug. Thanks, this is already fixed in the repository. Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From robin at icir.org Sun Oct 14 17:06:21 2007 From: robin at icir.org (Robin Sommer) Date: Sun, 14 Oct 2007 17:06:21 -0700 Subject: [Bro] How to reset value of the timer In-Reply-To: <001c01c80732$c7765780$2719320a@telxsi.com> References: <001c01c80732$c7765780$2719320a@telxsi.com> Message-ID: <20071015000621.GE14099@icir.org> On Fri, Oct 05, 2007 at 15:03 +0530, sangramkishore wrote: > doesn't comes within tcp_ACK_timeout (This sets to 6.5 sec). I want to > reset the value of tcp_ACK_timeout when Acknowledgment comes. Can you > give me solution for this? Generally you can't change the value of an existing timer. You need to cancel the previous one and the install a new one with the modified expire time. Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From robin at icir.org Sun Oct 14 17:08:43 2007 From: robin at icir.org (Robin Sommer) Date: Sun, 14 Oct 2007 17:08:43 -0700 Subject: [Bro] Trace Files In-Reply-To: <3854D748-6837-434C-81D1-1354C825210D@ll.mit.edu> References: <3854D748-6837-434C-81D1-1354C825210D@ll.mit.edu> Message-ID: <20071015000842.GF14099@icir.org> On Thu, Oct 04, 2007 at 11:55 -0400, Reed Porada wrote: > On the Bro wiki it mentions that Bro can be configured to output > captured packets that look suspicious. Which text are you refering to exactly? Apart form -w, the only other thing I can think of is the built-in dump_current_packet() whichs save the currently processed packet to disk---with the typical problem that this is not very well defined. Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From rporada at ll.mit.edu Mon Oct 15 05:51:11 2007 From: rporada at ll.mit.edu (Reed Porada) Date: Mon, 15 Oct 2007 08:51:11 -0400 Subject: [Bro] Trace Files In-Reply-To: <20071015000842.GF14099@icir.org> References: <3854D748-6837-434C-81D1-1354C825210D@ll.mit.edu> <20071015000842.GF14099@icir.org> Message-ID: <165AD456-2122-41F4-A3C9-E19558FAAD86@ll.mit.edu> On Oct 14, 2007, at 8:08 PM, Robin Sommer wrote: > > On Thu, Oct 04, 2007 at 11:55 -0400, Reed Porada wrote: > >> On the Bro wiki it mentions that Bro can be configured to output >> captured packets that look suspicious. > > Which text are you refering to exactly? Apart form -w, the only > other thing I can think of is the built-in dump_current_packet() > whichs save the currently processed packet to disk---with the > typical problem that this is not very well defined. http://www.bro-ids.org/wiki/index.php/User_Manual:_Bro_Output#Tracefiles The line there implies something more than -w, which may be simply dump_current_packet(). -Reed From robin at icir.org Mon Oct 15 09:41:01 2007 From: robin at icir.org (Robin Sommer) Date: Mon, 15 Oct 2007 09:41:01 -0700 Subject: [Bro] Trace Files In-Reply-To: <165AD456-2122-41F4-A3C9-E19558FAAD86@ll.mit.edu> References: <3854D748-6837-434C-81D1-1354C825210D@ll.mit.edu> <20071015000842.GF14099@icir.org> <165AD456-2122-41F4-A3C9-E19558FAAD86@ll.mit.edu> Message-ID: <20071015164101.GB19328@icir.org> On Mon, Oct 15, 2007 at 08:51 -0400, Reed Porada wrote: > The line there implies something more than -w, which may be simply > dump_current_packet(). Actually I'm not sure what this is refering too. :) Robin -- Robin Sommer * Phone +1 (510) 931-5555 * robin at icir.org ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org From rporada at ll.mit.edu Mon Oct 15 14:33:51 2007 From: rporada at ll.mit.edu (Reed Porada) Date: Mon, 15 Oct 2007 17:33:51 -0400 Subject: [Bro] HTTP and unmatched_HTTP_reply In-Reply-To: <20071015164101.GB19328@icir.org> References: <3854D748-6837-434C-81D1-1354C825210D@ll.mit.edu> <20071015000842.GF14099@icir.org> <165AD456-2122-41F4-A3C9-E19558FAAD86@ll.mit.edu> <20071015164101.GB19328@icir.org> Message-ID: <953652F1-C2A7-40F8-8D9F-C528B6B16718@ll.mit.edu> When running bro (1.3.2), I get several 'unmatched_HTTP_reply' statements, and looking at the output in http.log I get several ''. I then printed out the conn_id for these requests, then did a random sampling of those within the pcap. All of the sessions looked ok, as in no different then the successfully matched request/reply flows. What might cause these unmatched replies? Commandline: bro -r my.pcap http http-request http-reply http-body Thanks, -Reed From hsiaom26 at hotmail.com Wed Oct 17 09:01:00 2007 From: hsiaom26 at hotmail.com (Mike Hsiao) Date: Wed, 17 Oct 2007 12:01:00 -0400 Subject: [Bro] Sasser Policy? Message-ID: <790d85320710170901y64262fd1kea07560f1493af4e@mail.gmail.com> Hi, Currently, I'm studying the worm behaviors, such as Blaster, Sasser, ... . And the policy script blaster.bro can detects instances of the W32.Blaster. Is there any policy that can be used for detecting Sasser? Or any other scanning policy can capture the scanning event of Sasser worm? I would like to understand how (or what approaches) Bro to detect Sasser. Any help will be appreciated, thanks. Regards, Mike From jp.luiggi at free.fr Thu Oct 18 04:57:52 2007 From: jp.luiggi at free.fr (jean-philippe luiggi) Date: Thu, 18 Oct 2007 07:57:52 -0400 Subject: [Bro] Sasser Policy? In-Reply-To: <790d85320710170901y64262fd1kea07560f1493af4e@mail.gmail.com> References: <790d85320710170901y64262fd1kea07560f1493af4e@mail.gmail.com> Message-ID: <20071018075752.78b196de@localhost> On Wed, 17 Oct 2007 12:01:00 -0400 "Mike Hsiao" wrote: > Hi, > > Currently, I'm studying the worm behaviors, such as Blaster, > Sasser, ... . And the policy script blaster.bro can detects instances > of the W32.Blaster. > > Is there any policy that can be used for detecting Sasser? > Or any other scanning policy can capture the scanning event of Sasser > worm? I would like to understand how (or what approaches) Bro to > detect Sasser. > > Any help will be appreciated, thanks. Hello Mike, The way used by Sasser (version "A") is different from the one used by Blaster. First it tries to connect using port tcp/445 instead of tcp/135 then it'll donwload a binary using FTP (port tcp/5554) and then at least 128 threads are launched. Seeing "blaster.bro", it should not be too difficult to adapt it for Sasser (testing for several connections to port 445/tcp) So an idea, copy blaster.bro to sasser.bro, then modify the policy new policy : ==== const W32S_port = 445/tcp; const W32S_MIN_ATTEMPTS = 128 &redef; redef enum Notice += { W32S_SourceLocal, W32S_SourceRemote, }; event connection_attempt(c: connection) { if ( c$id$resp_p != W32S_port ) return; local ip = c$id$orig_h; if ( ip in w32s_reported ) return; if ( ip in w32s_scanned ) { add (w32s_scanned[ip])[c$id$resp_h]; if ( length(w32s_scanned[ip]) == W32S_MIN_ATTEMPTS ) { if ( is_local_addr(ip) ) NOTICE([$note=W32S_SourceLocal, $conn=c, $msg=fmt("W32.Sasser local source: %s", ip)]); else NOTICE([$note=W32S_SourceRemote, $conn=c, $msg=fmt("W32.Sasser remote source: %s",ip)]); add w32s_reported[ip]; } } else w32s_scanned[ip] = set(ip); ==== Hope this will you give some help (an improvement would be to detect connections to port tcp/5554). With regards, Jean-philippe. From rpang at cs.princeton.edu Thu Oct 18 07:10:07 2007 From: rpang at cs.princeton.edu (Ruoming Pang) Date: Thu, 18 Oct 2007 10:10:07 -0400 Subject: [Bro] Sasser Policy? In-Reply-To: <790d85320710170901y64262fd1kea07560f1493af4e@mail.gmail.com> References: <790d85320710170901y64262fd1kea07560f1493af4e@mail.gmail.com> Message-ID: On 10/17/07, Mike Hsiao wrote: > Hi, > > Currently, I'm studying the worm behaviors, such as Blaster, Sasser, ... . > And the policy script blaster.bro can detects instances of the W32.Blaster. > > Is there any policy that can be used for detecting Sasser? > Or any other scanning policy can capture the scanning event of Sasser worm? > I would like to understand how (or what approaches) Bro to detect Sasser. Hi Mike, Do you want to detect the particular malware Sasser or, more generally, the class of malware that exploits the same vulnerability as Sasser does? For latter, Bro has a DCE/RPC parser that exposes the interface and function of each RPC request and the one used by Sasser can be easily identified. Coupled with some length threshold it will make a pretty precise and robust Sasser vulnerability detector. Ruoming > Any help will be appreciated, thanks. > > Regards, > Mike > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > From research at webhostvision.com Wed Oct 24 05:23:36 2007 From: research at webhostvision.com (Research Team) Date: Wed, 24 Oct 2007 13:23:36 +0100 Subject: [Bro] signature header Message-ID: <000801c81638$b9407cd0$2bc17670$@com> Hi all Can someone help me with this header? header ip[16:4] I don't get it? What does it mean. I have read the manual but was not very helpful Thx Moukala. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071024/a849c951/attachment.html From basam at stream.aol.net Wed Oct 24 08:12:57 2007 From: basam at stream.aol.net (Sridhar Basam) Date: Wed, 24 Oct 2007 11:12:57 -0400 Subject: [Bro] signature header In-Reply-To: <000801c81638$b9407cd0$2bc17670$@com> References: <000801c81638$b9407cd0$2bc17670$@com> Message-ID: <471F60F9.9050305@stream.aol.net> It means you are reading 4 bytes starting at 16th byte. So if you line this up with your IP header, it matches the destination address in your datagrams. Sridhar Research Team wrote: > > Hi all > > > > Can someone help me with this header? > > > > header ip[16:4] > > > > I don't get it? What does it mean. I have read the manual but was not > very helpful > > > > Thx > > Moukala. > > ------------------------------------------------------------------------ > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20071024/8dfd120e/attachment.html From jp.luiggi at free.fr Wed Oct 24 08:28:08 2007 From: jp.luiggi at free.fr (Jean-Philippe Luiggi) Date: Wed, 24 Oct 2007 11:28:08 -0400 Subject: [Bro] signature header In-Reply-To: <000801c81638$b9407cd0$2bc17670$@com> References: <000801c81638$b9407cd0$2bc17670$@com> Message-ID: <20071024152808.GA25010@armada.mynetwork.local> On Wed, Oct 24, 2007 at 01:23:36PM +0100, Research Team wrote: > Hi all > > Can someone help me with this header? > > header ip[16:4] > > I don't get it? What does it mean. I have read the manual but was not very > helpful Hello, Speaking of pure tcpdump/libpcap definitions, we want to use 4 octets from position 16 in the ip header. And in this case, it seems to be the ip destination address. See http://en.wikipedia.org/wiki/IPv4/Header Please note taht iounting is done from '0' With regards, Jean-philippe. From mel at hackinthebox.org Tue Oct 30 10:45:25 2007 From: mel at hackinthebox.org (mel) Date: Wed, 31 Oct 2007 01:45:25 +0800 Subject: [Bro] Bro 1.3.2 failed to start in Leopard Message-ID: <47276DB5.6010003@hackinthebox.org> Hi all, configure, make, make install, and make install-brolite were successful on Leopard 10.5. However, bro failed to start when invoked using the rc script. Running bro from the command line against pcap files was successful. Is there anyway that I can debug this? --mel From jean-philippe.luiggi at didconcept.com Wed Oct 31 04:31:32 2007 From: jean-philippe.luiggi at didconcept.com (jean-philippe luiggi) Date: Wed, 31 Oct 2007 07:31:32 -0400 Subject: [Bro] Bro 1.3.2 failed to start in Leopard In-Reply-To: <47276DB5.6010003@hackinthebox.org> References: <47276DB5.6010003@hackinthebox.org> Message-ID: <20071031073132.6b014329@localhost> Hello, Do you've any displayed messages or something else you could give us ? We may try to help but with something to base itself. Best regards, Jean-philippe. On Wed, 31 Oct 2007 01:45:25 +0800 mel wrote: > Hi all, > > configure, make, make install, and make install-brolite were > successful on Leopard 10.5. However, bro failed to start when invoked > using the rc script. Running bro from the command line against pcap > files was successful. > > Is there anyway that I can debug this? > > --mel > > _______________________________________________ > Bro mailing list > bro at bro-ids.org > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro > > > > > > !DSPAM:1,4727a5b6263258697011158! From vern at icir.org Wed Oct 31 13:03:04 2007 From: vern at icir.org (Vern Paxson) Date: Wed, 31 Oct 2007 13:03:04 -0700 Subject: [Bro] http-body and binary content In-Reply-To: (Fri, 12 Oct 2007 09:59:07 EDT). Message-ID: <200710312003.l9VK37Fs014036@pork.ICSI.Berkeley.EDU> > The only thing I am still noticing is that with a print it appends a > newline to each print statement. Is there anyway to prevent this? Not presently, as it's built into "print". We have in mind a framework for controlling behavior like this, but no active work yet on implementing it. Vern From vern at icir.org Wed Oct 31 13:03:06 2007 From: vern at icir.org (Vern Paxson) Date: Wed, 31 Oct 2007 13:03:06 -0700 Subject: [Bro] HTTP and unmatched_HTTP_reply In-Reply-To: <953652F1-C2A7-40F8-8D9F-C528B6B16718@ll.mit.edu> (Mon, 15 Oct 2007 17:33:51 EDT). Message-ID: <200710312003.l9VK3AWb014040@pork.ICSI.Berkeley.EDU> > When running bro (1.3.2), I get several 'unmatched_HTTP_reply' > statements, and looking at the output in http.log I get several > ''. I then printed out the conn_id for these > requests, then did a random sampling of those within the pcap. All > of the sessions looked ok, as in no different then the successfully > matched request/reply flows. What might cause these unmatched replies? > > Commandline: > bro -r my.pcap http http-request http-reply http-body Any chance you could send us my.pcap? Vern