Hi,
I am new here.
I tried to get whole archive from majordomo for previous mailing
messages and looks like I am still waiting.
I was trying to compile the package under redhat 9.0.
I got the following error message in last link sentence.
I still got the same error even after I upgraded the bind to latest
redhat update (glibc-2.3.2-27.9).
nb_dns.o(.text+0x62d): In function `nb_dns_activity':
: undefined reference to `__ns_initparse'
nb_dns.o(.text+0x6f2): In function `nb_dns_activity':
: undefined reference to `_ns_flagdata'
nb_dns.o(.text+0x6f8): In function `nb_dns_activity':
: undefined reference to `_ns_flagdata'
nb_dns.o(.text+0x870): In function `nb_dns_activity':
: undefined reference to `__ns_parserr'
collect2: ld returned 1
Could anyone help me? Thanks!
Hongjie
--
-----------------------------------
Hongjie Xin Ph#: (919)248-1409
Network Research Engineer, FAX#:(919)248-1455
Advanced Network Research Group, MCNC-RDI hxin(a)anr.mcnc.org
> I've got warning during execution too :
>
> | ./bro: ./bro : WARNING: symbol(__p_class_syms) size mismatch relink your program
> | ./bro: ./bro : WARNING: symbol(__p_type_syms) size mismatch relink your program
Let me know if you still have this problem with the new 0.8a34 release.
Did you get the BIND dependencies worked out for OpenBSD?
Vern
> but when I put with mt.bro and worm.bro policy files. It makes segmentation
> fault. Worm analyzer doesn't work perfect now ?
You need to provide details and, if at all possible, a test case that
reproduces the problem. You should probably send these to me privately
rather than via the mailing list, unless others on the list indicate that
they've encountered a similar problem.
> and I have one more question. I want to add another virus/worm detection
> feature to Bro. (Likes Klez or Lovegate)
It would be best to do this using Bro's new signature engine. Currently,
worm.bro is only for detecting HTTP-based worms.
> But Manual is hard for me to do that job so I'm looking for information
> that can help me. Where can I find it ?
Unfortunately, it will be just as difficult, or more so, to explain how
to do this via email as for you to learn how to do so from the manual
plus inspecting the policy scripts that come with the Bro distribution.
Vern
Hi,
My name is Ji-Hoon, Lee and nice to meet you all
I have an interest in detecting network threats and measuring the loss of bandwidth caused by them.
So, I choose the Bro to detect them. I've read manual and installed Bro to my FreeBSD. It works good!!
and I also ran Tcpdump to record all packets on my local network for one day.
Today I put tcpdump file to the Bro to analysis with mt.bro policy file. Bro returns many weird logs and works good.
but when I put with mt.bro and worm.bro policy files. It makes segmentation fault. Worm analyzer doesn't work perfect now ?
and I have one more question. I want to add another virus/worm detection feature to Bro. (Likes Klez or Lovegate)
But Manual is hard for me to do that job so I'm looking for information that can help me. Where can I find it ?
Thank to reading my poor writing (Sometimes I think I have to study English first of all --") and hope you all have a nice weekend.
Hi,
I am interested to do some further testing of this, but does the a32
release have the fixes for the hashing issue inside? (I am referring to
their paper at: http://www.cs.rice.edu/~scrosby/hash/.)
Has this been extensively tested?
Tx!
Chris
> There must be a better way of using res_mkquery to assure that this
> calls in the nb_dns.c will work s expected.
I've asked Craig Leres (who wrote the nb_dns stuff, and is one of
Bro's autoconf maintainers) to look into this.
> I do note that nb_dns.h does
> not even exist on my Linux box
That's a Bro source file rather than a system file, so checking for it
won't help.
Vern
> Dict.cc: In member function `void* Dictionary::NextEntry(HashKey*&,
> IterCookie*&, int) const':
> Dict.cc:260: choosing `HashKey::HashKey(const void*, int, unsigned int)'
> over `
> HashKey::HashKey(void*, int, int)'
> Dict.cc:260: because worst conversion for the former is better than worst
> conversion for the latter
> Dict.cc:288: choosing `HashKey::HashKey(const void*, int, unsigned int)'
> over `
> HashKey::HashKey(void*, int, int)'
> Dict.cc:288: because worst conversion for the former is better than worst
> conversion for the latter
> make: *** [Dict.o] Error 1
>
>
> This error looks more programatic to fix, so this will take more time.
> Anyone with thoughts on this one?
Good catch by the compiler - this points out a warning in which two
calling sequences with quite different semantics could be confused due
to the implicit conversion rules.
I've changed the calling sequence of one of the calls to avoid the
possible ambiguity.
Vern
> I am interested to do some further testing of this, but does the a32
> release have the fixes for the hashing issue inside?
Yes, as indicated in the first item in CHANGES.
Vern
> A good example of the need for while loops is doing integer overflow
> detection in RPC services. To do it properly, you need to be able to
> check the length of each argument in the call (or response, since clients
> can be vulnerable as well...)
If Bro provided the arguments in generic form to the policy script
(it doesn't currently, it instead provides parsed versions) then it would
be as a table - so the existing "for" operator would serve for iterating
through them.
I'm pushing back here because I want to understand if there's a compelling
need to add this language feature. I think for many uses, the existing
features will serve. That said, I expect there *are* such cases where a
more general loop construct is needed. But I want to better understand
where those are needed, because it's not clear that C-style "while" or
"for" will be the best way for them. There are other paradigms. For
example, S has very powerful array-oriented operators, such that it's
quite rare you ever need to write a for or while loop.
Vern
> Either one, or both, would be extremely useful as far as I can see. I
> suppose there are reasons that these are not included, and it would be
> good to know those reasons. I assume that it is so that someone can't
> blow a hole in their foot, since if one doesn't do bounds checks, Bro
> would probably freak out.
It's not bounds checking, it's the possibility of spending a great deal
of time in a single function or event handler, which can lead to packet
drops.
> It would be nice if the actual bro pieces were threaded for various
> reasons. I'd assume that if it were a completely threaded app that the
> crashing behavior it seems to exhibit during load, the packet dropping,
> and other aspects could be seriously improved.
It might help, but it would also introduce a whole set of nasty-to-debug
race conditions. I want to avoid those if at all possible.
(Note, you can effect a degree of multi-threading by using events for
control flow.)
> Certainly to split off the BPF code into a spearate thread would
> allow it to read on ahead and not loose as much network traffic on a
> busy network
BPF already runs in a separate thread, namely the kernel, so there's no
further gain to be had here.
> while the actual parser/analyzers could be chugging along
> merrily in another (or other) thread/s.
There might indeed be a gain here. It would depend in part on how much
data structure locking is required.
> Anyone have the reasons that there is no for or while loops?
Per the above.
> And, what
> should be substituted in their place?
In what contexts do you find you need them?
Vern