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
-----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-----
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
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
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
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.
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
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
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
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
>
>
>
