I'm using bro 2.5.1 for network security monitoring , the message queue
is kafka componment (the bro-to-kafka plugin version is v0.5.0, librdkafka
version is v0.9.5).
Now i have encountered an error when network traffic up to 1.6Gbps, the
error message is segment fault from `src/Event.cc#90`, bro crashed.
The following listed is our test environment informations:
> CPU: 32 core Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
NIC: Speed 10000Mb/s
Storage: 2TB SATA, 100GB SSD
Below listed information is backtrace from core dump. (more on gist
> #0 SetNext (this=0x0, n=0x7fe292ebd490) at
> /opt/download/bro/src/Event.h:21 #1 EventMgr::QueueEvent (this=0xc302c0
> <mgr>, event=event@entry=0x7fe292ebd490) at
> /opt/download/bro/src/Event.cc:90 #2 0x00000000005fe6a7 in QueueEvent
> (obj=0x0, mgr=0x0, aid=0, src=0, vl=0x7fe2e2bedb80, h=..., this=<optimized
> out>) at /opt/download/bro/src/Event.h:88 #3 Reporter::DoLog
> (this=0x29aabb0, prefix=prefix@entry=0x908cd7 "error", event=...,
> out=0x0, conn=conn@entry=0x0, addl=addl@entry=0x0, location=location@entry=true,
> time=time@entry=true, postfix=postfix@entry=0x0, fmt=fmt@entry=0x7fe36c719d70
> "Kafka send failed: %s", ap=ap@entry=0x7fe36aa3eaf8) at
> /opt/download/bro/src/Reporter.cc:350 #4 0x00000000005fee8f in
> Reporter::Error (this=<optimized out>, fmt=fmt@entry=0x7fe36c719d70
> "Kafka send failed: %s") at /opt/download/bro/src/Reporter.cc:76 #5
> 0x00007fe36c717fa9 in logging::writer::KafkaWriter::DoWrite
> (this=0x6369270, num_fields=<optimized out>, fields=<optimized out>,
> vals=0x69d2080) at
> /opt/download/bro/aux/plugins/kafka/src/KafkaWriter.cc:156 #6
> 0x000000000089e495 in logging::WriterBackend::Write (this=0x6369270,
> arg_num_fields=<optimized out>, num_writes=1000, vals=0x6dc7bf0) at
> /opt/download/bro/src/logging/WriterBackend.cc:301 #7 0x0000000000662180
> in threading::MsgThread::Run (this=0x6369270) at
> /opt/download/bro/src/threading/MsgThread.cc:371 #8 0x000000000065eaa8 in
> threading::BasicThread::launcher (arg=0x6369270) at
> /opt/download/bro/src/threading/BasicThread.cc:205 #9 0x00007fe36e8ce2b0
> in ?? () from /lib64/libstdc++.so.6 #10 0x00007fe36ed2ce25 in start_thread
> () from /lib64/libpthread.so.0 #11 0x00007fe36e03634d in clone () from
Varibles on frame 1
(gdb) f 1 #1 EventMgr::QueueEvent (this=0xc302c0 <mgr>,
at /opt/download/bro/src/Event.cc:90 90 tail->SetNext(event); (gdb) info
args this = 0xc302c0 <mgr> event = 0x7fe292ebd490 (gdb) info locals done =
<optimized out> (gdb) p head $1 = (Event *) 0x7fe3540c81c0 (gdb) p tail $2
= (Event *) 0x0 (gdb) p event
> $3 = (Event *) 0x7fe292ebd490
During test, the variable `tail` is NULL pointer always when bro crashed,
however the variable `head` is NULL or not.
on my research, in the huge network traffic scenario, KakfaWriter write
log to kafka exceed the limit of
configuration `queue.buffering.max.messages(default is 100000)` or
`queue.buffering.max.kbytes(default is 4000000, 4G in other words)` in
and QUEUE_FULL error raised by librdkafka, then KafkaWriter call
Reporter::Error to report the runtime error.
so KafkaWriter::DoWrite lead too many action to call Reporter::Error
I guess the issue cause with concurrency access to the varible `tail`
without lock, then it set to be a NULL pointer, but i don't know why.
Then call the function `SetNext` with the NULL pointer, segment fault was
The above is my guesswork, maybe there is another reason.
Wish someone could help.
Does anyone have a reliable method to find Active Directory Golden or
Silver Tickets in the Bro Kerberos logs? I was planning to look into doing
this (maybe based partially on expiration) but wanted to ask the list
first. I appreciate any advice.
I'm sure others have experienced this, when updating Bro, packages with C++
components will need to be re-installed/rebuilt (sometimes, not always).
There may be some crazy C++ way of avoiding that, but outside of that I've
been trying to come up with options to suggest so our upgrade process can
be more easily automated.
What do folks think about a couple options to bro-pkg such as:
1) a new package.meta file field:
2) And a corresponding bro-pkg command: bro-pkg rebuild [nodeps]
Separately, but kinda related, I wouldn't mind a '--yes' flag or something
similar when packages aren't being installed interactively.
Alternatively, the idea has been tossed around that we build the bro
packages we use into RPMs, but then that sorta defeats the bro-pkg command
MITRE has created a plugin for Bro that adds an analyzer for the HTTP/2 protocol (RFC 7540) and released it open source at https://github.com/MITRECND/bro-http2
A little background on HTTP/2 – after using HTTP 1.x for the longest time companies wanted to come up with a successor protocol that took into consideration the changes that had occurred with the web since the creation of the HTTP 1.x specifications (HTTP 1.1, RFC 2616 came out in 1999!). This led to the creation of SPDY, realizing that SPDY was useful, the IETF took its concepts and formalized a new protocol and called it “HTTP/2”. HTTP/2 introduces a number of changes and improvements on top of HTTP 1.x including providing native multiplexed communication channels. HTTP/2 also completely changes the transport mechanism, now being a binary protocol (for those not intimately familiar with HTTP 1.x, it is a text-oriented protocol).
The analyzer has two dependencies – libnghttp2, available via apt (Ubuntu) and yum (CentOS EPEL) and brotli (not available via repos, only via github at https://github.com/google/brotli). It also currently doesn’t support the Bro Package Manager (this is on the todo list). After installing the plugin, it needs to be loaded, which can be done by putting “@load http2” into your bro policy/script file. This analyzer will create an http2.log file where http2 transactions will go to. For more information, reference the README on github.
There are a couple of very important caveats with using this analyzer. First, you will likely not see any HTTP2 traffic in the clear, pretty much ever, since the major browsers, afaik, have decided on only using HTTP/2 with TLS ALPN (RFC 7301). So, this means, to use this analyzer you will need to have some SSL/TLS interception capability in place to decrypt traffic and provide it to bro which will in turn allow this analyzer to analyze the traffic. If someone finds this to be untrue and sees a significant amount of http2 traffic in the clear, I’d like to hear about. Secondly, this analyzer doesn’t have a dpd.sig file so you’ll need to specify, explicitly, which ports to analyze – by default ports 80 and 443 are configured which should be good enough for most people. Lastly, this analyzer, although stable, still has some things on the to-do list and could probably use some more testing and feedback so if you decide to install/run it and run into an issue please contact us about it.
For those who have ssl logs and are interested in seeing how much HTTP/2 traffic their organization is seeing, take a look at the “next_protocol” column in ssl.log which indicates the ALPN negotiated protocol.
When you run Bro. Are all the protocols such as http, ftp etc enabled on
local.bro as default? Because i am not sure if i need to add all the
protocols manually or if they are already running as default?
The configuration is extracting certain file types but the files that are extracted are not authentic replications of the files in the stream. The hashes do no match the real files at the user’s endpoint. Upon inspecting the extracted files there seems to be mismatched and duplicated streams.
How can this be corrected? I would like the extracted files to be exactly what the user would download.
Thank you kindly for your help.