Recently I have some problems with Bro and PF_RING in cluster.
On my server, when I have less than 32 worker threads(rings),
everything is okay, but when I use worker threads more than 32, pf_ring
start to receive repeating data packets. For example, rings less than 32, I
send 400000 packets to server and pf_ring info in /proc shows there is
400000 packets in rings, but when rings greater than 32, I can get 800000
packets when 33 rings and 1200000 packets when 34 rings and so on.
I guess if there is some rules that a pf_ring or a bro cluster can only
support less than 32 rings or worker threads on a server or some other
Any insight would be helpful.
I was wondering if anyone knows any way for Bro ASCII writer to output
directly to FIFO file ?
I wish to output logs to FIFO file and have a reader app listening to it,
without the need for file postprocessor actions.
My Google-fu is failing me right now, so I wanted to reach out to the list
to see if anyone has ever attempted to use Zeek to detect packets with no
TCP flags set?
In Snort land, a signature would look something like this:
alert tcp $HOME_NET any -> $EXTERNAL_NET 443 (msg:"LOCAL Port 443 and no
TCP flags set"; flags:0; classtype:misc-activity; sid:7;)
Before anyone asks, I'll just ahead and state that "yes Virginia, these
packets do really exist in the real world..." (though rare).
Thanks in advance,
ISO files (ISO 9660 media images) - magic bytes 43 44 30 30 31 (CD001)
at offset(s). Is this omitted intentionally for any reason (confidence
or similar), or is it sensible to add a signature for this? Just
noting delivery of malicious ISO files as malware containers over
recent years. I notice recent libmagic having a couple of entries for
this. How would an update or addition typically happen?
this email is a short reminder of the upcoming Zeek Workshop Europe 2019
(April 9–11 @CERN, Geneva, Switzerland).
The program will consist of talks by the Bro development team and external
contributors. As in our last event, a large part of the development team
will be attending the workshop.
There are still a bunch of open spots - you can register at
https://indico.cern.ch/event/762505/ (also linked from https://zeek.org).
We also are still looking for presenters - if you have a topic that you
might want to give a talk about, please submit an talk abstract to
info(a)zeek.org. The deadline for this submission is February 25th, 2019.
Please note that there is a MISP training/workshop hosted at CERN right
after the Zeek workshop - you can find more information linked from the
Bro ftp log only seems to record file_size for files that are pulled down from the interwebs. It does not record file size for files that are uploaded. Is this the expected behavior? We are running bro-2.5.3. Any help would be appreciated.
I've been trying the get Zeek to work on a platform that does not support
I see that vdso has 4 syscalls out of which the first 3 are used in the
A few things that I already tried doing-
1. For the time being, removing all usages of "gettimeofday" and
2. Commenting out the following from cmake files and bro-config-
I'm not sure I'm doing everything to replace/remove the occurrences of the
syscalls because ldd still shows that the bro execuatble is linking to
linux-vdso.so and the LD logs show that symbols for those syscalls are
being fetched (segfaults at this point)
Please let me know if I'm missing something?
I have tried my Google-fu far and wide, but I have not found a
solution yet to operate Bro on a FIPS-enabled host. When FIPS is
enabled via the kernel, Bro refuses to start because of its use of
MD5. Any assistance in the matter would be appreciated.