From jean-marc.mulet at htd.ap-hop-paris.fr Wed Mar 8 04:06:53 2000 From: jean-marc.mulet at htd.ap-hop-paris.fr (Jean Marc Mulet) Date: Wed, 08 Mar 2000 13:06:53 +0100 Subject: bro and nestea attacks Message-ID: <38C6425D.3DF8B0D7@htd.ap-hop-paris.fr> 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 ). From k_k_yee at yahoo.com Tue Mar 14 22:19:38 2000 From: k_k_yee at yahoo.com (Kam K. Yee) Date: Tue, 14 Mar 2000 22:19:38 -0800 (PST) Subject: logging in bro Message-ID: <20000315061938.6284.qmail@web3501.mail.yahoo.com> 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 From vern at ee.lbl.gov Mon Mar 20 00:38:31 2000 From: vern at ee.lbl.gov (Vern Paxson) Date: Mon, 20 Mar 2000 00:38:31 PST Subject: logging in bro In-Reply-To: Your message of Tue, 14 Mar 2000 22:19:38 PST. Message-ID: <200003200838.e2K8cVH26878@daffy.ee.lbl.gov> > 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 From jean-marc.mulet at htd.ap-hop-paris.fr Mon Mar 20 08:52:00 2000 From: jean-marc.mulet at htd.ap-hop-paris.fr (Jean Marc Mulet) Date: Mon, 20 Mar 2000 17:52:00 +0100 Subject: segmentation fault Message-ID: <38D65730.5AA60670@htd.ap-hop-paris.fr> 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 From matt at cs.hmc.edu Fri Mar 24 19:33:02 2000 From: matt at cs.hmc.edu (Matt Schnaider) Date: Fri, 24 Mar 2000 19:33:02 -0800 (PST) Subject: Messages in Bro Message-ID: 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_ ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. From vern at ee.lbl.gov Fri Mar 24 20:01:35 2000 From: vern at ee.lbl.gov (Vern Paxson) Date: Fri, 24 Mar 2000 20:01:35 PST Subject: Messages in Bro In-Reply-To: Your message of Fri, 24 Mar 2000 19:33:02 PST. Message-ID: <200003250401.e2P41Z622100@daffy.ee.lbl.gov> > 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