Hi,
The following problem is probably easy, but my knowledge
of C++ is pretty limited.
I have a table defined in Bro, and I want to modify it
(add/delete terms) in C++. Actually, I want to modify the
table *only* in C++, but this is another subject.
I use internal_val() to get a Val* from the table's Bro name.
When I want to read the table, I access to the table
underneath using my_table->AsTable() or, if I want to
do further casting, using my_table->AsTable()->AsTableVal().
Everything works fine.
Problem is when I want to write. AsTable() is defined in
Val.h as a const accessor, but not as a non-const one. This
means that my_table->AsTable() returns actually a "const
TableEntryValPDict" object. Therefore, any access to Insert()
or Remove() causes a "discards qualifiers" compiler error.
While I can do brute-force cast and turn my "const
TableEntryValPDict" into a simple TableEntryValPDict, I've
read in Val.h that "Accessors for mutable values are called
AsNonConst* and are protected to avoid external state
changes." This seems to state that there is a valid reason
to avoid doing what I'm doing. "Avoid external state
changes" is not descriptive enough for me.
Can somebody provide advice on this?
TIA.
-Chema
Hi,
I've managed to create a native win32 DLL build of Broccoli, using the
MinGW environment (http://www.mingw.org) and the OpenSSL libraries
listed on http://www.openssl.org/related/binaries.html . Evidence:
http://www.cl.cam.ac.uk/~cpk25/broping.gif
This is broping running inside vmware on my laptop and pinging out to
Bro running on the Linux host system. (Apologies for the German window
title -- this is an installation of a Windows 98 CD that has a long
tradition in my family :)
MinGW rocks. I was able to use the entire gnuish build environment
including libtool, and moving to OpenSSL eliminated almost all
platform-dependent stuff. I can't seem to figure out nonblocking I/O on
Windows right now so it's blocking for the moment, but it's in the
works.
The new 0.5 release + the windows binaries are here in case you want to
give it a try:
http://www.cl.cam.ac.uk/~cpk25/downloads/broccoli/
Cheers,
Christian.
--
________________________________________________________________________
http://www.cl.cam.ac.uk/~cpk25http://www.whoop.org
Hi,
On Thu, 2004-07-22 at 07:55, Debra Dvorak wrote:
> Hello,
>
> Thank you so much for your reply. You were correct. I did not need the
> --with-package= part (I had thought maybe it was required for the it to
> complile with the linux include directory...that is not true). I do
> still have some questions and some clarifications to my earlier post:
> when installing I've typed the following:
> ./configure
> make
> make install
>
> the response I get from make install is as follows:
> >bro /usr/local/sbin
> > make: bro : Command not found
> > make: *** [install] Error 127
oops you're right, sorry. It appears make install is broken at this
point. We're not typically running make install here because Bro can run
just fine from its build tree, but this will certainly need to be fixed.
> Also another question. In the logs I am seeing "dropped 500 packets out
> of 504" or similar...my guess is that my machine is not fast enough for
> the event engine to process everything as it is being seen on the wire
> so some packets are being dropped without analysis? I am using a nessus
> scanning script against the network to see the response from bro....and
> it tends to send out the packets very fast...this may be an unrealistic
> attack since most attacks would not be as "noisy"...but it is a good way
> of testing the system to see if it is "reading" packets and alerting. I
> also have the capacity to upgrade double the system memory and will be
> doing that soon.
Well even if Nessus sends quickly, Bro shouldn't miss 99% of the packets
:) If the counters you're referring to are the ones pcap reports, then
the reason may be that packet counters are handled differently on Linux
and BSD. Do not trust these counters on Linux.
Good luck,
Christian.
--
________________________________________________________________________
http://www.cl.cam.ac.uk/~cpk25http://www.whoop.org
The Bro mailing list bro(a)bro-ids.org, which is currently hosted at
bro(a)lbl.gov, is being moved to bro(a)icsi.berkeley.edu. I've copied over
the subscriber list and you should have already (or soon) received an email
message from mailman-owner with your subscriber information. The list
is "live" but I haven't yet switched bro(a)bro-ids.org over to it yet.
I'll send a note when that happens. In the interim, you can use
bro(a)icsi.berkeley.edu directly (though in general, bro(a)bro-ids.org is
preferred).
A significant benefit of the new setup is Web-accessible archives. These
are in place except for the past few days of traffic, which I'm looking
into getting copied over, too.
If you encounter any initial problems, let me know.
Vern
> I have compiled it with the IPv6 option.
I don't think you could have (you do so by configuring using
"./configure --enable-brov6"), because currently the sources
don't compile due to the introduction of uses of addresses
(for example, in bro.bif) which need additional code to build
when addresses occupy > 1 word.
As I mentioned, this will eventually be fixed, but it's not
a priority for us at the moment due to more pressing needs.
If you want to contribute patches, that would certainly
be welcome.
Vern
Hello,
I am attempting to install and study bro as a grad project. I have RH 9
installed and all updates done. I have not hardened the system yet
because I don't want to disable something that will interfere with the
IDS.
I have the following installed (in installation order):
perl-Tk-804.027-8.rh9, zlib-1.2.1, libpcap-0.8.3, tcpdump-3.8.3,
mysql-4.0.15a, httpd-2.0.50, php-4.3.3.
I downloaded bro (bro-pub-0.8a87) to /root/bro directory and untarred.
I've tried installation with: ./configure --with-PACKAGE=linux-include,
make, make install. I am getting an error at the make install as
follows:
bro /usr/local/sbin
make: bro : Command not found
make: *** [install] Error 127
I've tried a couple of things:
./bro -r example-attacks/ntp-attack.trace mt this command gives some
expected errors about scan.bro variables, etc...but also gives the log
of the session. Using cat weird.log gives the following:
986505326.451411 128.3.9.239 > 128.3.9.62/ntp: truncated ntp.
using ./bro -i eth0 -w testinglog.trace mt yields the same expected
errors and then "listening on eth0" but when I end (ctl C). I get "0
packets recieved on interface eth0, 0 dropped" with the nic operating
both with an ip address and in "stealth mode". I am running nessus
against the network and ethereal on the network to detect the traffic so
there should be some traffic picked up on the interface (or I would
expect it to be). cat testlog.trace gives either nothing or the
following error:
./bro: problem with trace file testlog.trace -fread; inappropriate ioctl
for device.
Can someone please help me determine what is going wrong with the
installation and how to get bro to "see" the traffic?
Thank you in advance.
Best Regards,
Deb
Hi Vern,
I am currently looking for an IDS which has 'full' IPv6 support.
IPv6 is growing (althrough sometimes silently) and the worst scenario
would be that it gets the stigma that its the protocol of choice for
malicious wrongdoing since it has become the backdoor into your network.
If we are going to offer customers dual stack IPv4/IPv6 access and there
is no adequate support from the security tools that he/she normally uses
this can easily happen without even noticing, since we lack the tools to
look for this sort of activity.
I have compiled it with the IPv6 option.
How do I tell that IPv6 is working in Bro at all?
I don't see any events for IPv6 generated.
Regards,
Thomas
> -----Ursprungliche Nachricht-----
> Von: Vern Paxson [mailto:vern@icir.org]
> Gesendet: Samstag, 17. Juli 2004 01:25
> An: Scheffler, Thomas
> Betreff: Re: Bro IPv6
>
>
> > What is the status of IPv6 support in Bro?
>
> Bro supports IPv6 headers/addresses if configured using
> --enable-brov6.
> (It doesn't have any support for IPv6 options or ICMPs.) There's some
> bitrot in the code, though (it was developed quite a while ago, and we
> don't yet use it operationally), so it needs updating. This probably
> won't happen for a while, as it's not currently a priority for us.
>
> Vern
>
> What I'm doing in the attached patch is
>
> 1. check whether you're running Darwin
> 2. if so, test whether just including arpa/nameser.h gives you HEADER
> 3. if 2 fails, include arpa/nameser_compat.h and use -lresolv instead of
> /usr/lib/libresolv.a
Thanks, I've integrated this and it'll be included in the next release.
My Darwin setup is evidently a bit unusual (since I didn't encounter the
problems that Ruoming & Brian did), so if others can please test this when
it goes out, I'd appreciate it.
Vern
