zeek October 2007

zeek@lists.zeek.org

27 participants
25 discussions

by Reed Porada

I am looking at extending Bro to help with traffic isolation. What I need to be able to do is differentiate between traffic that matches a given set of criteria and that which does not. In general, I know this can be done through the policies, and I believe I can do most of what I want within a policy. There are a few things that from reading the documentation and some initial policy testing that I am not certain about. 1) Is it possible to denote particular packets in a capture? I know most of the analysis is done on a flow/connection basis, but I was wondering if any information regarding the pcap was kept in the streams/records that are passed? 2) Is it possible to get the content from http sessions? I want to be able to validate that the content is that which I know to be on a given site. I know there is a content_length and data_length values in the http_message record type, but I do not see much relating to the actual content. Thanks for any help, -Reed

14 years, 7 months

[Bro] question about bro alarm log

by mel

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

14 years, 7 months

[Bro] How to construct constant "time" values

by Fabian Schneider

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_Variable… 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(a)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

14 years, 7 months

[Bro] UDP flow anomaly

by CS Lee

Hi all, We are trying to write the simple script where it will check if the udp reply is 18 bytes and will return the src ip, dst ip as well as its bytes exchanges as illustrate as below src ip ------> dst ip src ip <----- dst ip (18 bytes) It is pretty simple and works well to detect the udp probing, and we are happy with it but when we test it on one of the packet capture which supposingly having 3 udp packets with 18 bytes return, it only detects one of it but didn't see the rest. And running through tcpdump, we figure this - 2007-09-13 07:32:30.298295 IP 192.168.0.185.63025 > 210.79.186.143.23074: UDP, length 22 2007-09-13 07:32:30.566344 IP 210.79.186.143.23074 > 192.168.0.185.63025: UDP, length 18 2007-09-13 07:32:34.790093 IP 192.168.0.185.63025 > 89.37.157.114.28763: UDP, length 41 2007-09-13 07:32:34.791688 IP 192.168.0.185.63025 > 200.83.176.80.49847: UDP, length 41 2007-09-13 07:32:34.809467 IP 192.168.0.185.63025 > 89.37.157.114.28763: UDP, length 33 2007-09-13 07:32:34.809531 IP 192.168.0.185.63025 > 200.83.176.80.49847: UDP, length 33 2007-09-13 07:32:35.331256 IP 200.83.176.80.49847 > 192.168.0.185.63025: UDP, length 19 *2007-09-13 07:32:35.350840 IP 200.83.176.80.49847 > 192.168.0.185.63025: UDP, length 18* 2007-09-13 07:32:35.403002 IP 89.37.157.114.28763 > 192.168.0.185.63025: UDP, length 19 *2007-09-13 07:32:35.407810 IP 89.37.157.114.28763 > 192.168.0.185.63025: UDP, length 18** * The script can locate the 210.79.186.143 but not 200.83.176.80 and 89.37.157.114. That lead us to believe that bro understand the flow in semantic level. In fact if we do the matching to 18+19 = 37 bytes, it detects the other 2. And just learn about the trace feature from scott, we immediately tried the trace and we found this - 1189639955.350840 /usr/local/stow/bro-1.3.2/policy/hot.bro:153 function called: check_hot(c = '[id=[orig_h=192.168.0.185, orig_p=6302 5/udp, resp_h=200.83.176.80, resp_p=49847/udp], orig=[size=74, state=1], resp=[*size=37*, state=1], start_time=1189639954.79169, duration= 0.559152126312256, service=, addl=, hot=0, history=Dd]', state = '2') .....blablabla another one Here's our simple and shameful script - *@load udp-common redef capture_filters += { ["udp"] = "udp" }; redef local_nets: set[subnet] = { 192.168.0.0/24 }; ** event udp_reply(u: connection) { local orig = u$id$orig_h; local resp = u$id$resp_h; local origs = u$orig$size; local resps = u$resp$size; if ( u$resp$size == 18) { print ("Suspected udp probe"); print fmt("%20s %5s %5s %5s", orig, resp, origs, resps); }* } I don't see we can use udp time out for this as the interval of return packet is too low. Or is there workaround to examine the first corresponding udp reply packet size. Thanks! -- Best Regards, CS Lee<geekooL[at]gmail.com>

14 years, 7 months

[Bro] Enhancing/Redefing records and Overloading functions

by Fabian Schneider

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(a)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

14 years, 7 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

zeek October 2007