zeek August 2005

zeek@lists.zeek.org

14 participants
32 discussions

by Mike Muratet

Greetings I am integrating bro into a larger system so that I can use it to keep track of connections (which seems easier than trying to write a method from scratch with pcap). I thought it would be straightforward to grep for print or email or alarm statements to figure out where to put the hooks for an IPC message but so far it eludes me. Is there a principal module for outputting the notifications? Thanks Mike

13 years, 5 months

Re: [Bro] Side effects on record fields when triggering events

by Vern Paxson

> Okay Chema and I tracked it down to the reference counting that is going > on in the core Exactly. Aggregates in Bro are passed as shallow copiess, not deep copies. There are times when it would be handy to have an operator to specify deep-copy semantics. I share your concern at the counter-intuitive behavior that shallow-copy semantics can provide, but blanket deep-copy can be very expensive, and needlessly so in many cases. Vern

15 years, 4 months

[Bro] Side effects on record fields when triggering events

by Christian Kreibich

Hi, is the following correct: when I trigger an event in the policy layer via the event() statement and pass a record value as an event argument, then at the time the triggered event is processed, the value is taken from the same location in memory that was passed to the event() statement. For example, this ... type foo: record { a: count &default = 0; }; event e1(f: foo) { print fmt("e1: %d", f$a); } event bro_init() { local f: foo; print fmt("bro_init: %d", f$a); event e1(f); ++f$a; } ... yields: bro_init: 0 e1: 1 So it seems that what is passed to the event handler is the value in its state before it goes out of scope (end of bro_init()). Any modifications of the record value that happen between the time of triggering the event and its processing will be visible to the event handler. Isn't that rather dangerous? My intuition was that an event() statement passes copies of all parameters to the event handlers to guarantee they all get the same values. I now do this manually where it is a problem in my policies. It gets more interesting -- why does the following work? type foo: record { a: count &default = 0; }; global bar: table[count] of foo; event e1(f: foo) { print fmt("e1: %d", f$a); } function f1(): foo { local f: foo; return f; } event bro_init() { bar[1] = f1(); print fmt("bro_init: %d", bar[1]$a); event e1(bar[1]); delete bar[1]; } It yields: bro_init: 0 e1: 0 After event e1 is triggered, the value passed to the e1 handler is erased from the global table. So why does this not give a run-time error? I'm confused at this point about the assumptions I can make about record values received by event handlers. If I missed the explanations of the call semantics in the manual then please point me to them, otherwise I think they should really be added... Thanks in advance! Christian. -- ________________________________________________________________________ http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org

15 years, 4 months

Re: [Bro] Bro install problems on linux

by Vern Paxson

> If I use the default configuration it segfaults As is always the case when reporting crashes, it is highly helpful if you can please include a debugger traceback showing the problem. Otherwise we're pretty much stuck with trying to fix it if it doesn't happen to reproduce in our development environments. Vern

15 years, 4 months

[Bro] successful_RPC_reply_to_invalid_request and ContentGap

by bchen＠cs.ucf.edu

Hi everyone, I used Bro to read a trace file that was captured from a local network. In Bro's log files, the majority of log records are about successful_RPC_reply_to_invalid_request and ContentGap. What situations can cause these two alerts? thanks Bing

15 years, 4 months

Re: [Bro] Bro install problems on linux

by Vern Paxson

> So I'm kinda guessing it might be related to 64bit > compatability if it's not just something i am doing wrong. Hmmm, that could be. You might try contacting Martin Arlitt <arlitt(a)cpsc.ucalgary.ca>, whom I believe has Bro working on 64-bit Linux, though I think he may have had to make some hacks to do so. Vern

15 years, 4 months

Re: coding style (Re: [Bro] Small bug in TCP_Rewriter)

by Vern Paxson

> As long as a (security tool, in particular) project has a style and enforces > it, that's what matters. Consistency makes everyone's life much easier when > they go through the code. Agreed. I'm also these days not a big fan of Bro's current style, but like to keep it uniform. The students I work with like it even less :-), and in fact an item on our wish-list is to find a good pretty-printer so we can automate things to ensure consistency. (This will also be an opportunity to change the style somewhat.) Vern

15 years, 4 months

Re: [Bro] Intrusion prevention

by Vern Paxson

> Will it be interfacing with a firewall like iptables (like snort-inline does) ? It's a different API, and not directly suitable for use with something like iptables (our approach is quite fine-grained). Note, we already (and for a long time) run Bro in a reactive fashion, for which the policy script can drop hostile traffic. But this isn't the full power of an IPS since there's latency between discovering a problem and blocking a host, so damage can still occur. Vern

15 years, 4 months

Re: [Bro] reliable off-line protocol detection

by Vern Paxson

> smtp.dump > > > 1124785239.632272 127.0.0.1/56034 > 127.0.0.1/778 ftp-sig > > 1124785306.080354 127.0.0.1/56037 > 127.0.0.1/778 ftp-sig > > 1124785591.602025 127.0.0.1/56048 > 127.0.0.1/778 ftp-sig > > 1124785606.143460 127.0.0.1/56050 > 127.0.0.1/778 ftp-sig > > WHY? ( =A91992 Annie Lennox) The FTP backdoor detector isn't precise - it looks for initial 220 or 426 replies, which SMTP servers can generate too. Ideally, the SMTP detector would trigger first (based on seeing EHLO or HELO). If you have a simple trace that shows it's failing to do so, go ahead and send it to me and I'll see what's up. Vern

15 years, 4 months

Re: [Bro] Intrusion prevention

by Vern Paxson

> Is there any plan to make Bro run in 'inline' mode as an IPS ? We're doing this as part of a DOE-sponsored project for coupling Bro with custom hardware (per Chema's comments about his thesis work). The resulting design will support Bro running as a stand-alone IPS (i.e., without needing the custom hardware), though that's not our near-term focus. Vern

15 years, 5 months

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 August 2005