Hi all,
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
reasons?
Any insight would be helpful.
Alan Commike's Bro protocol analyzer talk from BroCon 18 on YouTube is missing the slides link (https://www.youtube.com/watch?v=UtEe-VTPcDY&t=145s).
Looks like the slides for other talks are hosted at https://www.zeek.org/brocon2018/slides/ but directory indexing has been turned off.
Could anyone share those with me, please?
Thanks,
Kay
Kay Avila
Senior Security Engineer, Cybersecurity and Networking Division
National Center for Supercomputing Applications (NCSA)
University of Illinois, Urbana-Champaign
P: (217) 300-1754 F: (217) 244-1987
Hi Zeek-devs,
I am not sure I am getting it right, but i t seems to me that a Zeek logger in a cluster configuration simply sits there waiting for logs and then writes them down. Does it do any additional work? For example, checking for duplicated logs from workers? If yes, where is the code for this additional checks?
Mauro
Hi Team,
I am working on a Zeek script and would like to understand how can I make
Zeek look only for the first ten packets in a tcp session.The first ten
packets are enough to fingerprint the traffic I am trying to identify and
so would to ensure my script also looks at only the first 10 packets to
save processing time.
The communication is as follows :
There is the initial 3 way handshake and then there are 7 packets with
variable lengths and on a non-default destination port/service. So I had to
use the tcp_packet event in my script. Is there a better way of doing it ?
Using tcp_packet would make my script to check for all tcp packets
increasing the load on my zeek system.
Please do let me know if you have any suggestions for me on this. Looking
forward to your response.
Thanks,
Manju Lalwani
Hi,
I was hoping to understand how Zeek aggregates packets by connection. Is there any documentation that summarizes the approach? Is there a way to extract all the packets that correspond to a particular connection?
Thank you,
Ananditha Raghunath - 0557
Assistant Staff
Cyber Operations and Analysis Technology
MIT Lincoln Laboratory
ananditha.raghunath(a)ll.mit.edu | 781-981-9035
Hello fellow Zeekers,
I am new to the mailing list and fairly new to Zeek.
I am having an issue where DNS traffic is duplicated. It seem fairly
obvious to me that the issue is that the manager is sending a single
"session" to all of the workers defined in node.cfg.
Example duplicate logs (sanitized a bit):
user1@site1bro:~$ awk -F '\t' '{ if($1 == "1558556089.463824") print $0;}'
dns.date-time.log
1558556089.463824 Ce6WGH1tX7fUQCJkEb 10.1.1.1 49675 10.5.5.5 53 udp 58613 -
yahoo.uservoice.com 1 C_INTERNET 1 A - - F F T F 0 SITE1BRO-4
1558556089.463824 CxhWh33b65uCcQlUR2 10.1.1.1 49675 10.5.5.5 53 udp 58613 -
yahoo.uservoice.com 1 C_INTERNET 1 A - - F F T F 0 SITE1BRO-8
1558556089.463824 CNBy3ykdFSvXydiW7 10.1.1.1 49675 10.5.5.5 53 udp 58613 -
yahoo.uservoice.com 1 C_INTERNET 1 A - - F F T F 0 SITE1BRO-9
1558556089.463824 CV6w2f3NKeaAwhAvJf 10.1.1.1 49675 10.5.5.5 53 udp 58613 -
yahoo.uservoice.com 1 C_INTERNET 1 A - - F F T F 0 SITE1BRO-7
1558556089.463824 Cc5rcP3N92OGHYUKA2 10.1.1.1 49675 10.5.5.5 53 udp 58613 -
yahoo.uservoice.com 1 C_INTERNET 1 A - - F F T F 0 SITE1BRO-6
My node.cfg file:
[manager]
type=manager
host=10.10.10.10
[proxy-1]
type=proxy
host=10.10.10.10
[SITE1BRO]
type=worker
host=10.10.10.10
interface=eth5
lb_method=pf_ring
lb_procs=10
pin_cpus=2,3,4,5,6,7,8,9,10,11
Other info:
- The span feed is clean of duplicates (validated with multiple packet
captures)
- Other logs are generally not duplicated, and I suspect that this only
happens with UDP traffic
- I've tried changing the LB type in the broctl.cfg file to 2-tuple,
5-tuple, and round-robin (4-tuple is default) but none of those resolved
the issue
- I've tried installing the latest dev version of pf_ring to no avail
- From previously archived threads, it appears that this is not a new
issue, and that it also happens with af_packet ... which is what I was
going to try next :(
Any insights as to how I can fix, or at least filter these duplicates
before they are written to file and/or sent to Kafka would be greatly
appreciated.
KCL
Hi all,
The minutes from the 17 May 2019 LT Meeting can be found at:
https://blog.zeek.org/2019/05/open-source-leadership-team-meeting.html
Please let us know if you have any questions, comments, feedback or
suggestions for topics for the the LT to discuss.
Also a reminded that the Registration and Call for Participation for
ZeekWeek 2019 is now open. If you want to suggest a presentation topic or
presentation or if you want to become a sponsor please go to:
https://www.zeekweek.com
Thanks,
~Amber
--
*Amber Graner*
Director of Community
Corelight, Inc
828.582.9469
* Ask me about how you can participate in the Zeek (formerly Bro)
community.
* Remember - ZEEK AND YOU SHALL FIND!!
Hello,
I'm novice in zeek use and command line interpretation. But when I did this command, I get the below error:
~/bro$ bro -r 09052019.pcap /home/salwa/bro/scripts/base/protocols/modbus/main.zeek
fatal error in /home/salwa/bro/scripts/base/protocols/modbus/main.zeek, line 5: can't find ./consts
My goal is to analyze my pcap file with zeek and extract the maximum of statistics to train my neural network. The more statistics I have, the better my learning of the neural network. That's why I used the modbus script but I ignore the reason of the above error.
Thanks in advance for your help.
Best regards,
Salwa
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
A security patch release, Bro v2.6.2, is now available for download:
https://www.zeek.org/download/index.html
The following Denial of Service vulnerabilities are addressed:
* Integer type mismatches in BinPAC-generated parser code and Bro
analyzer code may allow for crafted packet data to cause
unintentional code paths in the analysis logic to be taken due to
unsafe integer conversions causing the parser and analysis logic
to each expect different fields to have been parsed. One such
example, reported by Maksim Shudrak, causes the Kerberos analyzer
to dereference a null pointer. CVE-2019-12175 was assigned for
this issue.
* The Kerberos parser allows for several fields to be left
uninitialized, but they were not marked with an &optional attribute
and several usages lacked existence checks. Crafted packet data
could potentially cause an attempt to access such uninitialized
fields, generate a runtime error/exception, and leak memory.
Existence checks and &optional attributes have been added to the
relevent Kerberos fields.
* BinPAC-generated protocol parsers commonly contain fields whose
length is derived from other packet input, and for those that allow
for incremental parsing, BinPAC did not impose a limit on how
large such a field could grow, allowing for remotely-controlled
packet data to cause growth of BinPAC's flowbuffer bounded only
by the numeric limit of an unsigned 64-bit integer, leading
to memory exhaustion. There is now a generalized limit for
how large flowbuffers are allowed to grow, tunable by setting
"BinPAC::flowbuffer_capacity_max".
-----BEGIN PGP SIGNATURE-----
iQIzBAEBAgAdFiEE6WkLK32KwaGfkhxKxotJTfVqzH4FAlzvRkwACgkQxotJTfVq
zH4pLA//SO5JEvq1OLU5MFUvaMD2FraqcAsE/nj7+Yt+UbyRqG3NAwdgE19ZmtCb
bRTbHpdnRo+chM+JdtB+alyojgAt0sBtMQyVqMSR2UhQgCn68OJvCT9Qi7FbCI/q
ZqxKYwZ9Lfrgx4EJWnbS2hNhrBsSt9kBtqm/6YsPjyIIk3zt4q5xxJwaAouQIDFy
DxTQqwaIeDNvjjV9HxYkzrWJINt4CzxG512yfXBgX1sRa2rNAhiSGOubd6uFjkWu
WABfzJUDQILN0RiefT8MilEf1OBCcLtUNhVAnIgqkUkmkWm48VZu2Sup6THwU3nU
N3x8XFYBLLbV3+l1dt8fqWAyzBPWs2irQBY2xmPT2xBkq4gQXxlR1Le41b/hZXCJ
azmmDepedm6vfSl2Q0S9wNqEVpFAx98wj7cGZuce4VLom3W0ANl67jchXrzIX2UT
BZ78jc50F8+FM7/yjYsUf+kd5t6zOWGSCq2iraZBDOaNKa1bVKBirbmFySkVuCDt
fKXyLw7OKSsZD18P2SVQWHKv/JdfOTm7SRixm5Sbr+yNFceNU0KTrMSu8WI+4kxE
qpVSjbMqf5XpUWZYygtGZQgg5lsrgArkOWoIfxldGDLpjQM5vUdvY3uJEdOxIsZT
AmdS3SFoorzHPhKywiSANRbGdMn4o8E3y1UCdyoerKrZJoy2ZZc=
=XuB+
-----END PGP SIGNATURE-----
