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
The problem:
type MyRecord = record {
f1: SomeRecordType;
f2: bytestring &length=body_len;
} &let {
body_len: uint32 = f1.rec_len - sizeof (f1);
};
The above definition looks familiar, uh? It is a simplifed version of
the DCE RPC PDU. If MyRecord is incrementally parsed, the sizeof (f1)
in the &let construct will cause trouble because getFieldBegin and
getFieldEnd can only be used for non-incremental parsed record. If
the size of SomeRecordType is decideable statically (in the case of
DCE RPC, it is), then the patch fixes the problem. Now we can make
the PDU incrementally parsed.
Cheers,
Jimmy
____________________________________________________________
The future is not set. There is no fate but what we make
for ourselves. - Terminator II, Judgment Day
------------------------------------------------------------
Hi,
I notice that in ~RPC_Reply, there is a statement "delete call_;". However,
this call_ is instantiated by calling t_context->connection()->FindCall(
msg()->xid()). This means that it is not "new"ed. This call_ supposely is
deleted in the ~RPC_Message. Thus, there is a potential double-free here.
The root cause is that binpac generates the "delete call_" for &let field.
This is incorrect behavior. However, I haven't figured out how to fix it
in binpac.
A quick fix to this problem is to modify the rpc-protocol.pac:RPC_Reply,
replacing the RPC_AcceptedReply(call) and RPC_RejectedReply(call) with:
RPC_AcceptedReply($context.conn.FindCall(msg.xid))
RPC_RejectedReply($context.conn.FindCall(msg.xid))
Cheers,
Jimmy
____________________________________________________________
The future is not set. There is no fate but what we make
for ourselves. - Terminator II, Judgment Day
------------------------------------------------------------
Hello,
Just a simple question, why do we've some files which start with
t=<epoch_time> ("alarm/notice") and others with just <epoch_time>
("arp/conn") ?
I ask this because i'm writing a little script and it'll
be more easy to only have one format. :-)
Best regards,
Jean-philippe.
Hello,
I've a little question, why do we've some files (log) which start with
t=<epoch_time>, example : alarm/notice and others with just <epoch_time>,
example : arp/conn ?
I ask this because i'm writing a little script and it'll
be more easy to only have one format. :-)
Another thing, i'm thinking about adding one more parameter in bro.cfg, we
may use it to specify if we want the log's time in epoch 's time or 'normal'
time.
What to do think about this ?
Best regards,
Jean-philippe.
Hello,
I am working on the function NetSessions::BuildHeader and I have two
questions :
- This function is called in NetSessions::DoNextPacket just after a "if
( new_packet )" but this condition seems to be always false.
Is there something to activate to make it work ?
- As NetSessions::BuildHeader takes in parameter "const struct ip* ip" I
have two solutions to make it work with IPv6 : copy this function and
adapt it for IPv6 or change the prototype to :
"NetSessions::BuildHeader(const IP_Hdr* hdr)".
I have currently chosen the second option, but I'd like to hear what you
think about that before I make too much changes.
Thank you,
Julien Desfossez
Hi all,
I have followed the steps here -
http://www.bro-ids.org/wiki/index.php/GeoLocation but when I configure
bro-1.3, I have this -
Bro Configuration Summary
==========================================================
- Debugging enabled: no
- OpenSSL support: yes
- Non-blocking main loop: yes
- Non-blocking resolver: yes
- Installation prefix: /usr/local/stow/bro-1.3-GEOIP
- Perl interpreter: /usr/local/bin/perl5
- Using basic_string: yes
- Using libmagic: Yes
- Using libclamav: No
- Binpac used: shipped with Bro
- Using libGeoIP: No
- Pcap used: system-provided
How can I force it to enable GeoIP support.
Thanks.
--
Best Regards,
CS Lee<geekooL[at]gmail.com>
This week we had the first Bro Hands-On Workshop at the San Diego
Supercomputer Center.
The workshop's web page now contains all the material we used
(slides and exercises with templates and solutions):
http://www.bro-ids.org/bro-workshop-2007/agenda.html
As this material makes actually some nice, up-to-date documentation,
it's also available in the Wiki at:
http://www.bro-ids.org/wiki/index.php/WorkshopMaterial
Thanks to everybody who attended the workshop! (Some slides have
been slightly updated so those who have been there might want to
update their local copies.)
Robin
--
Robin Sommer * Phone +1 (510) 931-5555 * robin(a)icir.org
LBNL/ICSI * Fax +1 (510) 666-2956 * www.icir.org
FYI, the pre-test has been updated to:
http://www.icir.org/vern/tmp/bro-1.2.18.tar.gz
with the main changes being fixes for ICMP messages that include non-TCP/UDP
excerpts, and a BinPAC portability tweak.
Vern
