> Has anyone built a list of the possible messages that bro can generate
If you mean the events generated by the event engine, just look in bro.init
for the event handlers it defines. (Look also for the many "weird" events,
listed in weird.bro.) If you mean the messages generated by the default
policy scripts, the only way to determine those is to grep the scripts for
"log" and "print", unfortunately.
> (and possibly some interpretations?)
This, alas, is a significant shortcoming. The only documentation is
the Bro paper and in the source code (and some in the policy scripts).
After the Adelaide IETF (which I'm leaving for in another hour), I will
have a major portion of my time freed up, and the #1 project for how to
use that time is to write a comprehensive user manual.
> Also, if
> anyone could explain what "telnet ack above a hole" means, I'd appreciate
> it. Thanks.
This means that Bro saw an acknowledgement for sequence # S, but the maximum
data it saw the sender transmit was S', for S' < S. This should never occur
for a correctly functioning TCP. Unfortunately, there *are* incorrectly
functioning TCPs that will sometimes do this; and, sometimes Bro gets confused
(when connections are reused) and erroneously generates this message; *and*,
it can also occur when the packet filter has dropped packets (i.e., data S
was in fact sent, but Bro never saw it). It's this last that motivated
checking for the condition and genreating the message - because it often
is telling you that Bro is dropping packets, which, unfortunately, the packet
filter sometimes itself doesn't know (i.e., the drop statistics are not
always reliable).
Vern
Hi,
Has anyone built a list of the possible messages that bro can generate
(and possibly some interpretations?)? If so please let me know. Also, if
anyone could explain what "telnet ack above a hole" means, I'd appreciate
it. Thanks.
-Matt
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Matthew J. Schnaider East 121
Harvey Mudd College x72006
340 E. Foothill Blvd. Class of 2001
Claremont, CA 91711 Computer Science Department Staff
"For starters, what is an echo and what does it do? The echo program reads a
string and repeats it; think of the program as an automated liberal arts
undergraduate student."
-- Stephen Northcutt _Network Intrusion: An Analyst's Handbook_
._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
Hello
Since on month I'm looking for a problem on bro
when I test it with a nestea attack it make a segmentation fault it
seems that the problem comes from the
Sessions.cc file in the
ListVal * NetSessions::BuildConnKey(uint32 src_addr, uint32 dst_addr,
uint32 src_port, uint32 dst_port) member fonction the second line :
key = new ListVal(TYPE_ANY);
it seems to be the TYPE_ANY that make problem if I replace it by
TYPE_NET (for example) I have a scan line ...: internal error :
heterogeneous list in ListVal::Append
if someone can help me find the error
Thank's in advance
> I have been working with the log files in bro (weird.log, bro.log,
> ftp.log, etc) and have noticed that they are written out in chunks of 4096
> bytes.
>
> I know that this is possibly done for performance reasons, but has anyone
> tried/done writing out to the log files in "real-time" (i.e., as soon
> there is data to be written out (i.e., without buffering))?
I've been wanting to add a flush directive, and/or a signal handler
(for HUP, say) that would flush the files, but haven't gotten around to
it yet.
> I have looked through the code looking for how and where this "buffering"
> is specified and how the "chunk size" is specified to be 4096, but have
> not had much success.
It's just the default size used by stdio. On my development system (FreeBSD),
it's 8192 bytes, by the way.
Note, though, that bro.log should be written unbuffered. If it's buffered
on your system, something strange is going on - there's an explict fflush()
in Logger.cc to make sure it goes out each time it's written.
Vern
I have been working with the log files in bro (weird.log, bro.log,
ftp.log, etc) and have noticed that they are written out in chunks of 4096
bytes.
I know that this is possibly done for performance reasons, but has anyone
tried/done writing out to the log files in "real-time" (i.e., as soon
there is data to be written out (i.e., without buffering))?
I have looked through the code looking for how and where this "buffering"
is specified and how the "chunk size" is specified to be 4096, but have
not had much success.
Does anyone know?
Thanks in advance!
=====
Regards,
Kam K. Yee
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Hello,
I looking for information, I compile bro V6.0 alpha on Linux (kernel
2.2.5-15)
at the compilation I have a message when it execute the command bison
-y -dtv parse.y
--> conflicts : 3 shift/reduce
It makes then the Bro binaire then I 'm running the command :
bro -i eth0 scan
On an over computer I running nessus ( a program that makes most known
attacks )
--> bro show the scanning and when the nestea attack begin then a
Segmentation Fault appear and bro stop
I just want to known if the problem is a porting problem ( what appen on
Sun ? ) or if it's a bro bug .
If someone want to test this I can get a full tcpdump file of the nestea
attack ( just ask me the file )
Thanks in Advance ( and thank to Vern Paxon for this program ).
