zeek June 2009

zeek@lists.zeek.org

17 participants
11 discussions

[Bro] segmentation fault on first packet

by Terry Barker

I'm having trouble running bro 1.4 that I recently installed on a solaris computer (uname -a gives: SunOS fsm04 5.9 Generic_118558-39 sun4u sparc SUNW,Sun-Fire-V890). I've installed and run bro on linux boxes several times over the last couple of years and know the basics. The program core dumps on the first packet of several pcap files I’ve tried. For example, I tried bro on a pcap file used in a recent bro workshop tutorial called trace1.tcpdump, and I've attached the first 20 packets (in test.tcpdump) just to be sure we're on the same page. If I run bro -r test.tcpdump I get a segmentation fault on the first packet. This is the output from gdb ...... ________________________________________________________ warning: Temporarily disabling breakpoints for unloaded shared library "/usr/lib/ld.so.1" Program received signal SIGSEGV, Segmentation fault. ConnCompressor::PktHdrToPendingConn (this=0x494c9c, time=964800422.39454699, key=0x491788, ip=0x0, tp=0x397cf4, c=0x494c9c) at ConnCompressor.cc:617 617 c->time = time; (gdb) where #0 ConnCompressor::PktHdrToPendingConn (this=0x494c9c, time=964800422.39454699, key=0x491788, ip=0x0, tp=0x397cf4, c=0x494c9c) at ConnCompressor.cc:617 #1 0x000cd410 in ConnCompressor::FirstFromOrig (this=0x396e18, t=964800422.39454699, key=0x491788, ip=0xffbfe1c0, tp=0x397cf4) at ConnCompressor.cc:276 #2 0x000cdc7c in ConnCompressor::NextPacket (this=0x396e18, t=964800422.39454699, key=0x491788, ip=0xffbfe1c0, hdr=0x397760, pkt=0x397cd2 "") at ConnCompressor.cc:234 #3 0x001b6cb8 in NetSessions::DoNextPacket (this=0x3984f0, t=964800422.39454699, hdr=0x397760, ip_hdr=0xffbfe1c0, pkt=0x397cd2 "", hdr_size=14) at Sessions.cc:611 #4 0x001b73e8 in NetSessions::NextPacket (this=0x3984f0, t=964800422.39454699, hdr=0x397760, pkt=0x397cd2 "", hdr_size=14, pkt_elem=0x0) at Sessions.cc:305 #5 0x00176bf0 in net_packet_dispatch (t=964800422.39454699, hdr=0x397760, pkt=0x397cd2 "", hdr_size=14, src_ps=0x397728, pkt_elem=0x0) at Net.cc:434 #6 0x00176e54 in net_packet_arrival (t=964800422.39454699, hdr=0x397760, pkt=0x397cd2 "", hdr_size=14, src_ps=0x397728) at Net.cc:496 #7 0x001863a4 in PktSrc::Process (this=0x397728) at PktSrc.cc:199 #8 0x00177380 in net_run () at Net.cc:526 #9 0x0009c230 in main (argc=3550208, argv=0x362c00) at main.cc:977 ________________________________________________________ If I run bro with -t bro -t -r test.tcpdump this is the result: ________________________________________________________ Execution tracing ON. ./test.tcpdump, line 1: error: unrecognized character - ¡ ./test.tcpdump, line 1: error: unrecognized character - ² ./test.tcpdump, line 1: error: unrecognized character - Ã ./test.tcpdump, line 1: error: unrecognized character - Ô ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - Ð ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ¯ ./test.tcpdump, line 1: error: unrecognized character - ¦ ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ÿ ./test.tcpdump, line 1: error: unrecognized character - í ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - @ ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - @ ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - € ./test.tcpdump, line 1: error: unrecognized character - Â ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - ./test.tcpdump, line 1: error: unrecognized character - Õ ./test.tcpdump, line 1: error: parse error, at or near "JA" ________________________________________________________ followed by the seg fault. Any advice would be appreciated. Terry

12 years, 11 months

[Bro] Hardware Experience

by Nick Buraglio

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good afternoon, list. I'm hoping to get a quick opinion on some hardware. I've done some brief looking and not really found what I'm seeking so I'll post here in hopes that one of you can share some experience. I'm exploring deployment of some Bro boxes and was hoping to leverage a great deal that Sun is offering to get the hardware. I know that the boxes can do what I need them to do, as I've worked on Bro implementations elsewhere. What I'd really like to know is if anyone has used the Sun (Intel Chipset 82598) dual port 10g cards? They're a decent savings of capitol, but I'd rather just spend the money to get the cards I'm used to (single port 10g Intel or Myricom) if the dual port cards behave strangely or are a time-vortex to get working. I'm making an assumption that the dual port cards operate similar to the single port cards. Has anyone used these in a bro deployment? Thanks, nb - --- Nick Buraglio Network Engineer, CITES, University of Illinois GPG key 0x2E5B44F4 Phone: 217.244.6428 buraglio(a)illinois.edu -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkn/OGkACgkQFOm2Sy5bRPRR1gCeKRIAGYMLVoygM/MnQiXJL4+u gpUAmQFpLOx+OxVXRZR3b11hkn+nwZ1k =rx7J -----END PGP SIGNATURE-----

12 years, 11 months

[Bro] Bro IDS installation

by Wong, Ming-Shih

Dear Sir or Madam, We are new to Bro IDS and having some problem installing the system. Some of your documents are a bit out-dated. For example, "Bro Quick Start Guide" is dated 2004 for FreeBSD 4.10. Our box is installed with FreeBSD 7.2. We followed the guide to compile the source code, ./configure, make, make install and make install-brolite. We also manually executed the "bro_config" script to configure the system. But then executing "bro.rc start" failed and returned an error like "can't open .....". Could anyone provide some quick help? Thanks. Best regards, Mike Wong General Dynamics - Advanced Information Systems (210)442-4255

12 years, 11 months

[Bro] Fwd: Some Questions, please

by shan shan

Good Afternoon.My questions are as follows: Q1. I can not solve the problem when doing bro_config, and the command lines are in the attached file config.txt . I do not know whether my configuration is setup right. Because I only get a log file in the /usr/local/bro/logs fold (in the attached file info.localhost.09-06-25_13.25.33). In the /usr/local/bro/reports folder there is no report file. Are the report generated automatically? Or shuld I generate it by hand? Q2. In the quick-Start file, I find that the report example. At the end of the report, there is a list of connections(only first 25 after alarm are listed). I want to ask: if there is no alarm, will there be no connections list (such as time and byte information)? And Bro can list only first 25 connections after alarm ? If I want the information of all connections, how can I get that? Thank you very much! I am looking forward for your reply.[?] -- Zhu Shan -- Zhu Shan -- Zhu Shan

12 years, 12 months

[Bro] Is there any way to flush the conn log every so often

by William L. Jones

I have a connection that I am monitoring with a low amount of activity so the conn log rarely fills up enough to be flushed to disk. I would like to force a flush on it every so often. Is there a way to do this through a bro config file. Bill Jones

12 years, 12 months

[Bro] Patch for BitTorrent analyzer

by Martin Szydlowski

Hi Bro Team, This is a patch that extends the functionality of the BitTorrent analyzer added by Nadi Sarrar and Bernd Ager. In particular, it will parse many popular extensions to the official protocol and also the azureus messaging protocol which uses a different message format. The patch has been thoroughly tested on off-line traces without causing problems. I am attaching the patch for both the 1.4 release and the latest svn revision (r6773) available and also a short description of the changes. greetz Martin -- Martin Szydlowski Vienna University of Technology (temporary @ UC Santa Barbara) Secure Systems Lab https://www.iseclab.org/ e-mail: msz(a)iseclab.org Changes: - added support for parsing of Azureus Messaging Protocol - added support for parsing of Extension Protocol and Fast Extensions - changed PDU-len to be always the actual size of PDU (including 4-byte length field) instead of hardcoded values based on message type - added policy to print the list of clients the tracker sends instead of just the count - fixed bug when converting tracker peer-lists to bro datatypes Caveats: - Not tested with Extension Negotiation Protocol: worst case is a (false) ProtocolViolation error.

13 years

[Bro] SSH login brute force

by Adayadil Thomas

Greetings. Does bro detect SSH brute force login attempts? I saw that there was ssh and ssh-stepping policies, and they do not seem to be looking for any kind of brute force detection, but I wanted to ask the group about this. Thanks for the reply, Thomas

13 years

[Bro] svn error updating source

by Randolph Reitz

While trying to update the tree... [brother@gumshoe ~/work]$ svn info Path: . URL: http://svn.icir.org/bro/branches/robin/work Repository Root: http://svn.icir.org/bro Repository UUID: 040645db-9414-0410-b69e-f32faa466a09 Revision: 6761 Node Kind: directory Schedule: normal Last Changed Author: robin Last Changed Rev: 6702 Last Changed Date: 2009-05-07 16:06:55 -0500 (Thu, 07 May 2009) I get this error... svn: Server sent unexpected return value (403 Forbidden) in response to OPTIONS request for 'http://svn.icir.org/bro' When I re-run 'svn update', more files are update and then the same error appears. Thanks, Randy

13 years

[Bro] Stand-alone cluster problems

by Tyler T. Schoenke

Hi, Just wondering if anyone has run into this problem. I'm running Robin's 1.4 cluster code on a stand-alone AMD dual-core machine that is monitoring a 200 Mbit connection. I've been running this setup for a couple months, and it has been working well. I noticed that Bro seemed to be missing some packets, and Seth told me to look for DroppedPackets in the notice.log. From what I recall, I was dropping upwards of 90% of the packets after filtering. The strange thing was the primary bro process CPU usage seemed to be low (20-30%), even though it was dropping most of the packets. I would have expected CPU to be high in trying to keep up. Is there some throttling mechanism to prevent the CPU from being maxed out? I turned on some restrict filters to bring the DroppedPackets down. I turned off various things like HTTP, HTTPS, DNS, IMAP, SMTP, and a few others. After that, the ratio of (packets dropped after filtering) to received was less than one percent. So that is the history and here is my problem. When I start the cluster, the above mentioned ratio will be less than 1%. It remains less than 1% for several days to a week. For no explicable reason, it will jump up as high as 99% and stay stuck there. This has happened twice in the last couple weeks. Whatever caused this problem also caused the logs to stop being rotated. They are showing a timestamp of June 7th (MST). When I run a cluster status, it shows the cluster is running, and I can see both bro-1.4-robin processes running, but their CPU usage has dropped down to 0.00%. I think the CPU usage for one of those processes had typically been around 16-20% when the dropped ratio was less than 1%. Restarting the cluster should clear the problem again for a few days. Is there any other troubleshooting I can do before restarting to determine the cause of the problem? Below are a few lines showing the high ratio of dropped packets. These are some of the last lines logged, so based on the timestamps, everything stopped around 01:48 6/8/09 GMT. 1244425212.229043:DroppedPackets:NOTICE_FILE:bro::::::::::317741 packets dropped after filtering, 387325 received, 1117174 on link::@26-c775-10c8ed 1244425222.229050:DroppedPackets:NOTICE_FILE:bro::::::::::16000 packets dropped after filtering, 68358 received, 192124 on link::@26-c775-10c91b 1244425236.737126:DroppedPackets:NOTICE_FILE:bro::::::::::311615 packets dropped after filtering, 341963 received, 979510 on link::@26-c775-10c939 1244425247.488693:DroppedPackets:NOTICE_FILE:bro::::::::::79770 packets dropped after filtering, 172843 received, 477468 on link::@26-c775-10c981 1244425261.942659:DroppedPackets:NOTICE_FILE:bro::::::::::315110 packets dropped after filtering, 315358 received, 878859 on link::@26-c775-10c987 1244425690.711860:DroppedPackets:NOTICE_FILE:bro::::::::::10878167 packets dropped after filtering, 10878305 received, 31316595 on link::@26-c775-10c994 Here are some earlier logs showing what the ratio normally looks like. 1243649373.579172:DroppedPackets:NOTICE_FILE:bro::::::::::1752 packets dropped after filtering, 333996 received, 612544 on link::@88-1bd3-bd5af 1243649383.579295:DroppedPackets:NOTICE_FILE:bro::::::::::1333 packets dropped after filtering, 342521 received, 627890 on link::@88-1bd3-bd5c2 1243649393.579339:DroppedPackets:NOTICE_FILE:bro::::::::::920 packets dropped after filtering, 326511 received, 605614 on link::@88-1bd3-bd5d1 1243649403.579424:DroppedPackets:NOTICE_FILE:bro::::::::::1336 packets dropped after filtering, 318679 received, 615016 on link::@88-1bd3-bd5ec Tyler -- Tyler Schoenke IT Security Office University of Colorado - Boulder

13 years

Re: [Bro] Hardware Experience

by Martin Holste

Cool! But I can't believe you're Bro instance is doing much inspecting if it's receiving line-rate packets and only using 1% CPU. As I said before, the majority of the CPU time is usually in pattern matching and protocol decoding (which is basically pattern matching), so I'm assuming that unless the pattern matching is also hardware accelerated, you're not pattern matching much of the traffic being sent to Bro. Is that the case? Thanks, Martin On Tue, Jun 16, 2009 at 9:34 AM, Jens Christophersen <jc(a)napatech.com>wrote: > Hi Jason and Martin, > > > > I have with interest read mail tread about Napatech NT20E adapters. > > > > The NT20E adapter is able to capture data at line speed for any frame size > from 64 bytes to 10000 bytes without slicing the frames. The NT20E support > many forms of slicing so the NT20E adapter can be setup to slice frames if > you want to reduce the amount of data transferred to the server memory, but > for a “Bro” application you probably don’t want to slice frames. > > > > If you want high “Bro” performance I can recommend that you setup the NT20E > to distribute frames to the number of CPU cores in your server (e.g. 8) > based on 5-tuple hash key. When you are using the Napatech zero-copy LibPCAP > you start the Napatech LibPcap library with a command file with the > following commands: > > DeleteFilter = All > > SetupPacketFeedEngine[ TimeStampFormat=PCAP; > > DescriptorType=PCAP; > > MaxLatency=1000; > > SegmentSize=4096; > > Numfeeds=8 ] > > PacketFeedCreate[ NumSegments=128; Feed=(0..7) ] > > HashMode = Hash5TupleSorted > > Capture[ Feed = (0..7) ] = All > > > > Then frames are distributed to the 8 CPUs with a server CPU utilization of > less than 1% at full network load, so you have the full server CPU for your > Bro application. > > > > Best regards, Jens > > > *Yours Sincerely*** > > *Jens Christophersen*** > > *Chief Technology Officer* > > > > *Napatech A/S* > > Tobaksvejen 23A Phone: +45 4596 1500 > > DK-2860 Søborg Fax: +45 6980 2970 > > Denmark Mobile: +45 3091 5773 > > www.napatech.com E-mail: jc(a)napatech.com > > >

13 years

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

zeek June 2009