Bro Workshop 2009, the 2nd.
===========================
The Bro team and the Lawrence Berkeley National Lab are pleased to
announce a further "Bro Workshop", a 2.5-day Bro training event that
will take place in Berkeley, CA, on October 13-15, 2009.
The workshop is primarily targeted at site security personnel
wishing to learn more about how Bro works, how to use its scripting
language and how to generally customize the system based on a site's
local policy.
Similar to previous workshops, the agenda will be an informal mix of
tutorial-style presentations and hands-on lab sessions. No prior
knowledge about using Bro is assumed though attendees should be
familiar with Unix shell usage as well as with typical networking
tools like tcpdump and Wireshark.
All participants are expected to bring a Unix-based (Linux, Mac OS X,
FreeBSD) laptop with a working Bro configuration. We will provide
sample trace files to work with.
This workshop will again be hosted by the Lawrence Berkeley National
Lab, and it will be located at the Hotel Durant in Berkeley. We will
soon provide a web site with more detailed registration and location
information. To facilitate a productive lab environment, the number
of attendees will be limited to 30 people. A registration fee of
$125 will be charged.
We also expect to have time for 2-3 case-study presentations from
people using Bro in their environments. If you have something you
would like to talk about, please send me a mail.
Looking forward to a great workshop,
Robin
--
Robin Sommer * Phone +1 (510) 666-2886 * robin(a)icir.org
ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org
We are gearing up for a Bro 1.5 release and would like to solicit
some testing of the current codebase to weed out any potentially
remaining issues ahead of time.
This applies in particular to a new
installation/configuration/maintenance framework called
"BroControl", which will ship as part of Bro 1.5, replacing the old
BroLite system that has already been deprecated for a while now.
BroControl allows for easy operation of a Bro setup, both for
standard single-system installations as well as in cluster setups.
It includes functionality for configuration, log archival, mail
notifications, dynamic updates, and general monitoring.
We'd much appreciate if folks could give our current development
version of Bro 1.5 and BroControl a try. In particular, trying
BroControl in both standalone and cluster operation on different
operating systems would be very helpful. So far, FreeBSD has seen
most testing, MacOS quite a bit, Linux only a little bit.
To get a copy of the current code base, use SVN:
svn checkout http://svn.icir.org/bro/trunk/bro
You need to run "./autogen.sh" after the checkout before proceeding
with the normal ./configure.
The default installation process should work as usual. For using
BroControl, see its documentation at
http://svn.icir.org/bro/trunk/bro/aux/broctl/README.html
If you find any problems, or something important missing, please
file a ticket with the Bro issue tracker at
http://tracker.icir.org/bro
When filing a ticket regarding BroControl, please make sure to set
the ticket's component to "BroControl".
For folks running a previous version of the "cluster shell" from my
work-branch: BroControl is more or less a rebranding of the shell
and supersedes all previous versions. See below for update
instructions.
Finally, if you give this version try, please drop me a quick mail
even if things are going smoothly for you so that we can keep track
the testing this version has seen.
Thanks a lot in advance,
Robin
--------- Update instruction ---------------------------------------------
For those folks already running a cluster installation using my work
branch updating to trunk with broctl should be easy. Just follow
these steps:
1. Backup the following files:
- All *.cfg files found in $prefix/etc
- The current set of logs in $prefix/logs
- Your site policies if they are installed somewhere under $prefix
2. Delete $prefix on all nodes (or at least anything Bro related in
there).
3. Follow the installation instructions in
http://svn.icir.org/bro/trunk/bro/aux/broctl/README.html
Skip the steps involving any of the *.cfg files.
Make sure to update the cron entry to use "broctl" instead of
"cluster".
4. Copy the saved files back into place:
- Copy all *.cfg back into $prefix/etc. Rename "cluster.cfg" to
"broctl.cfg".
- Copy the logs back into $prefix/logs.
- Copy your site policies back. The new default location for them
is $prefix/share/bro/policy/local. Copy them there or to whatever
path your broctl.cfg specifies.
6. Run "broctl install", then "broctl check" to make sure everythign
works as expected.
Generally, everything should be working as before. The main
differences to the old cluster shell are (1) the executable is now
called "broctl" instead of "cluster"; and (2) "broctl install" does
no longer copy any files from the Bro distribution directory into
the installation; you need to rerun "make install-broctl" if
anything inside the Bro distribution has changed (like after an "svn
update").
--
Robin Sommer * Phone +1 (510) 666-2886 * robin(a)icir.org
ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm trying to collect event_notice and event_alarm events from a
bro 1.4 instance via broccoli and seeing some odd behavior, and was
wondering if its something others have seen (and figured out).
What happens is the client connects, and requests those events,
and the server logs the connection and the request for events.
Everything looks fine, except that nothing comes through, and the bro
child/communicatons process starts to bloat up rapidly. Eventually the
process becomes huge and seg faults, leaving the parent bro processing
humming along happily. The entire time, not a single event arrives at
the client.
It almost looks as if the events are sent over to the child
process where they queue up for delivery, yet nothing goes through. I
saw that there is the suppress_notice_action flag which is set to F,
but the description sounds like it suppressed events arriving from a
remotero.
I am able to use the same client, and collect connection_finished
events, with no sign of the bro child process bloating up and dying,
so it seems to be something related to the event_notice and
event_alarm events. The NoticeAction and notice_info types passed for
those events are more complex than the connection_finished params,
would the optional fields and enumerated types in NoticeAction and
notice_info cause problems for marshalling and sending?
Thanks,
Steve
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqDDioACgkQcVd2YI1BWAiMrgCeNSeMQ0H0fPurC+iy4yY3+O1r
MbEAn3+i9gBi5m2iJzyoNwlcKIOJgZlW
=uNHe
-----END PGP SIGNATURE-----
Hello Bro Team:
I am encountering the following error which is crashing bro ( Version 1.4):
1249941643.081538 <no location> (127.0.0.2): bad tag in Val::CONST_ACCESSOR (types/string)
I can provide you more information as required.
Any thoughts?
Thanks
Aashish Sharma
Hi everyone
I have a got a problem. I want to call a function called world but it is
throwing the following error:
line 1: error: unknown identifier world, at or near "world"
global a: table[count] of string &default = world;
a[1] = "navdeep";
a[2] = "singh";
print a[2];
function world(): string
{
print "hello world";
}
Please resolve the problem.
Regards
Navdeep
Hi
I am new to bro but really interested working in bro. I have already started
the work. I am encountering a problem now.
It is about records. Let me explain wid the help of example:
type con: record
{
orig_h: addr;
orig_p: port;
resp_h: addr;
resp_p: port;
};
type con2: record
{
orig_h: addr;
orig_p: port;
resp_h: addr;
resp_p: port;
num_notices: count &optional;
};
function fun()
{
local id: con;
local id2: con2;
id2 = id;
}
This is giving segmentation fault , the statement id2=id. But in
documentation of bro , they have said this is absolutely right. Please
explain this.
Regards
Navdeep
