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
> 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
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/~cpk25http://www.whoop.org
> 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
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
> 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
> 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
> 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
> 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
> 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