> I was looking for ANY feedback on
> what others were doing with bro and received NOTHING. So I assume people
> are not really using it for any detection, but just as an educational tool
> (which is fine!).
Well, LBL and UCB use it 24x7 for detection, quite effectively. I know
some other sites are running it seriously, too.
> I continue to play with various polciies. Some combinations crash bro,
> some produce config parsing errors, some cause it to die a slow death,
> etc.
Rather than just stating these as generalities, please send along specifics
so they can be investigated/fixed. (Feel free to do this privately if
you want.)
> Here is what I use now:
Yep, that's what a number of our boxes use, except replace:
> @load http
with @load http-reply in order to pick up HTTP requests & replies.
> It works, doesn't detect much, some fun FTP attacks and weird RST packets
Do you know if things are indeed being missed?
Vern
> I was wondering if there is (or SHOULD BE) a repository of useful *.bro
> policies to use for different cases. Right now I am running with '@load
> mt' and some other @load's which I semi-intelligently selected from the
> policies dir, but I noticed there is a bunch of other fun bro files. Which
> of them are useful and when?
Well, it all depends on (1) your threat model, (2) how much load you can
afford. I welcome suggestions about ways to organize these (and/or others
that folks want to contribute) and experiences on which to use in what sorts
of contexts.
> Also, I understand that rules.bro is undocumented, but can I get ANY hints
> on its functionality beyond what I can figure from looking at the files
> itself...?
You should hold off on that a bit. Robin has written a chapter for the
Bro manual that describes the signature-matching, but the code is right
now still somewhat in flux. (Also note that rules.bro has been renamed
signatures.bro with the next Bro release.) This should be straightened
out within a few weeks, though, as we're now ramping up at LBL to run with
the signatures operationally.
> BTW, I was also about to ask how to best collect and analyze alerts, but I
> my have an answer to this one. Our product might soon collect Bro alerts
> and report on them (in the context of other security event messages).
Experiences/approaches in this regard will likewise be interesting to hear!
Vern
> Can you try the attached patch? There seems to be some incompatibility
> from gcc <3.0 to >= 3.0.
Umesh Shankar devised a cleaner fix, which I've appended.
I'll get out a new "CURRENT" release within the coming week.
Vern
--- DebugCmds.cc.ORIG 2003/01/22 09:08:15 1.14
+++ DebugCmds.cc 2003/01/23 21:09:40
@@ -161,7 +161,7 @@
for ( int j = 0; j < g_DebugCmdInfos[i]->NumNames(); ++j )
{
const char* curr_name = g_DebugCmdInfos[i]->Names()[j];
- if ( prefix.compare(0, arglen, curr_name) )
+ if ( strncmp(curr_name, prefix.c_str(), arglen) )
continue;
// If exact match, then only return that one.
I've been trying to get bro to compile properly under FreeBSD 5.0. It looks
like the change to gcc3 broke some things. I've attached a patch that gets
the compile further along than initially, but I got stuck. Of course this
causes the compiler to kvetch about using depricated headers. Here's the
error message that has me stumped:
g++ -I. -Ilibedit -O -c DebugCmds.cc
In file included from /usr/include/g++/backward/map.h:59,
from Type.h:29,
from ID.h:25,
from Expr.h:28,
from Debug.h:25,
from DebugCmds.cc:11:
/usr/include/g++/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warning use -Wno-deprecated.
DebugCmds.cc: In function `int find_all_matching_cmds(const std::string&, const
char**)':
DebugCmds.cc:164: invalid conversion from `const char*' to `unsigned int'
DebugCmds.cc:164: initializing argument 1 of `int std::basic_string<_CharT,
_Traits, _Alloc>::compare(_Alloc::size_type, _Alloc::size_type, const
_CharT*) const [with _CharT = char, _Traits = std::char_traits<char>, _Alloc
= std::allocator<char>]'
DebugCmds.cc:164: invalid conversion from `unsigned int' to `const char*'
DebugCmds.cc:164: initializing argument 3 of `int std::basic_string<_CharT,
_Traits, _Alloc>::compare(_Alloc::size_type, _Alloc::size_type, const
_CharT*) const [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]'
*** Error code 1
I can't seem to get it to find the hash<> templates.
I'm guessing that someone with more experience in C++ would be able to see
what's going on. I have very little experience with templates, etc in C++.
Also, the parse.y doesn't seem to be compatible with bison, I had to force
the Makefile to use the system yacc (byacc).
Jon
--
Jon Dugan | Senior Network Engineer, NCSA Network Research
jdugan(a)ncsa.uiuc.edu | 269 CAB, 605 E Springfield, Champaign, IL 61820
217-244-7715 | http://www.ncsa.uiuc.edu/~jdugan/
Vern and all,
Bro is up and running on our site, thanks to this list for the help with
the compilation!
I was wondering if there is (or SHOULD BE) a repository of useful *.bro
policies to use for different cases. Right now I am running with '@load
mt' and some other @load's which I semi-intelligently selected from the
policies dir, but I noticed there is a bunch of other fun bro files. Which
of them are useful and when?
Also, I understand that rules.bro is undocumented, but can I get ANY hints
on its functionality beyond what I can figure from looking at the files
itself...?
BTW, I was also about to ask how to best collect and analyze alerts, but I
my have an answer to this one. Our product might soon collect Bro alerts
and report on them (in the context of other security event messages).
Best,
--
Anton Chuvakin, Ph.D., GCIA - http://www.info-secure.org
Senior Security Analyst
netForensics - http://www.netForensics.com
732-393-6071
> in my policy file: redef restrict_filter = "vlan";
Oops. Unfortunately, "vlan" is a hack bolted onto tcpdump/libpcap.
I discussed bugs in it that Bro tickled with Bill Fenner a while ago.
Here's the tail end of that thread, which included a patch that worked for
one of your NCSA colleagues.
> no problem. tcpdump works fine with the above expression.. seems to work :)
>
> so now, in bro, I use the redef capture_filter = <above expression>
There were also some related problems with Bro reading from multiple
interfaces, because the vlan keyword diddles the hdr_size in a non-reentrant
way (or at least it used to), but I don't know if that's what's tripping
you up or not.
Does Bro work okay for you w/o the "vlan"?
Vern
Date: Mon, 5 Nov 2001 00:02:49 -0600
From: Jon Dugan <jdugan(a)ncsa.uiuc.edu>
Subject: Re: expression rejects all packets
To: Bill Fenner <fenner(a)research.att.com>
Cc: vern(a)ee.lbl.gov, tony(a)ncsa.uiuc.edu
X-Envelope-From: jdugan(a)ncsa.uiuc.edu
Resent-To: fenner(a)research.att.com, vern(a)ee.lbl.gov
Bill,
Well, I finally got a chance to try this patch -- it does indeed fix the
problem.
Thanks!
On Wed, Sep 12, 2001 at 08:47:34PM -0700, Bill Fenner wrote:
>
> Here's a not very elegant patch to try; it fixes the multiple compilation
> problem in my test program (not bro, just a filter expression tester).
>
> Bill
>
> Index: gencode.c
> ===================================================================
> RCS file: /tcpdump/master/libpcap/gencode.c,v
> retrieving revision 1.157
> diff -u -r1.157 gencode.c
> --- gencode.c 2001/07/03 19:15:47 1.157
> +++ gencode.c 2001/09/13 03:36:41
> @@ -78,6 +78,9 @@
> static jmp_buf top_ctx;
> static pcap_t *bpf_pcap;
>
> +/* Hack for updating VLAN offsets. */
> +static u_int orig_linktype = -1, orig_nl = -1;
> +
> /* XXX */
> #ifdef PCAP_FDDIPAD
> int pcap_fddipad = PCAP_FDDIPAD;
> @@ -551,6 +554,9 @@
> {
> linktype = type;
>
> + orig_linktype = -1;
> + orig_nl = -1;
> +
> switch (type) {
>
> case DLT_ARCNET:
> @@ -3873,7 +3879,6 @@
> gen_vlan(vlan_num)
> int vlan_num;
> {
> - static u_int orig_linktype = -1, orig_nl = -1;
> struct block *b0;
>
> /*
--
Jon Dugan | Senior Network Engineer, NCSA Network Development
jdugan(a)ncsa.uiuc.edu | 269 CAB, 605 E Springfield, Champaign, IL 61820
217-244-7715 | http://www.ncsa.uiuc.edu/people/jdugan
Hi,
I'm a recent subscriber, so if this has been covered, please point me.
I am working on getting bro bro-pub-0.8a20 up and running on freebsd box.
We have bro-pub-0.7a90 running using an old hacked version of libpcap
to handle vlans.
Anyway, I've updated to 0.7 of libpcap and compiled bro 0.8.
in my policy file: redef restrict_filter = "vlan";
so my resulting filter is
(((((((((((ip[6:2] & 0x3fff != 0) and tcp) or (tcp[13] & 7 != 0)) or (port finger)) or (tcp port 113)) or (port ftp)) or (port telnet or tcp port 513)) or (port 111)) or (udp port 123)) or (udp port 69)) and vlan)
libpcap promptly complains: expression rejects all packets
however if I rephrase it to be:
(vlan and ((((((((((ip[6:2] & 0x3fff != 0) and tcp) or (tcp[13] & 7 != 0)) or (port finger)) or (tcp port 113)) or (port ftp)) or (port telnet or tcp port 513)) or (port 111)) or (udp port 123)) or (udp port 69)))
no problem. tcpdump works fine with the above expression.. seems to work :)
so now, in bro, I use the redef capture_filter = <above expression>
bro runs, but no packets are being captured.
(i.e bro -w tcp policyFile; the tcp file is empty)
I also updated the PktSrc::SetHdrSize() to be
DLT_EN10MB:
hdr_size = 18; /* it was 14 */
but still no luck..
can anyone help me out??
thanks a ton,
mike haberman
NCSA
