Brim: Open-source desktop app to analyze large pcaps through the lens of Zeek
github.com
github.com
Wireshark performs poorly with opening such a large trace. Since Engineer's are costing well north of $150 per hour, having them twiddle their thumbs waiting is not economical or efficient.
Enabling a survey and filtering of the data as soon as possible from the pcap file will allow interactive examination. With Brim that identified data can be exported as a filtered, and thus much smaller file. This is similar to what tools such as Riverbed's Packet Analyzer do. PA is a .net front end to tshark type filtering and reporting. It ships with a number of useful filters to survey for common problems.[1]
Brim and Zeek appear to fill the need between Packet Analyzer on one hand and a regular Wireshark workflow on the other.
[1]: https://www.riverbed.com/products/steelcentral/steelcentral-...
What is zeek and can I use it to analyze wireshark captures?
Both Wireshark and Zeek use libpcap, which is the de facto standard for raw packet captures, so yes, the same data you'd be feeding to Wireshark to browse, you can also feed to Zeek to analyze.
https://www.csoonline.com/article/3313050/zeek-a-free-powerf...
As to the where - I guess I need to find some port that can give me a mirror of traffic.... But not that easy with heterogeneous lan+cloud+SaaS setup to figure out where/how to source "all" network traffic :/
Disclosures: Wireshark pays for my mortgage. My employer makes Packet Analyzer. I'm friends with people at Brim.
One key aspect of Zeek is that it can be deployed within a network to passively generate logs. As an incident response consultant, the few times I've worked with a client with Zeek logs, our ability to answer some critical questions in short order was increased dramatically! Back in my Sysadmin days, I used to run Zeek (when it was called Bro) to provide network logs for security review but also for general network analysis.
You can definitely run a pcap capture by wireshark through Zeek. you'd run `zeek -r <yourpcap>` and you'll end up with some lovely TSV separated logs in your current working directory!
Full transparency: I'm not part of the Zeek team, but I did author the original Zeek scripting guide for them back in 2012 or so. For my money, the Zeek team is building some of the better network appliances and detection/logging capabilities available.
It’s more of a Network Security Monitoring tool (NSM) than a Wireshark equivalent
It’s primary use case is to have a server(s) ingesting all traffic in a network and forwarding the traffic metadata to something like an Elastic Stack.
What makes it so powerful though, is that it actually has its own scripting language that allows you create automations based off what type of traffic is observed and these can be super intricate
The first one I authored myself many years ago and has been dormant for a long time although I'd certainly enjoy working on it again if an opportunity arises: https://github.com/rixed/junkie
The other one seems to stand in the same niche of highly specific, optimised programmable DPI, but I'm obviously much less familiar with it: https://github.com/DanieleDeSensi/peafowl
Brendan Gregg wrote a book that digs really deep into the bpf system. [2] I recommend you check it out if you need to do real work fast.
[1]: https://docs.splunk.com/Documentation/StreamApp/7.2.0/Deploy... [2]: http://www.brendangregg.com/bpf-performance-tools-book.html
"Then in 2013, Alexei Starovoitov completely reshaped it, started to add new functionalities and to improve the performances of BPF. This new version is designated as eBPF (for “extended BPF”), while the former becomes cBPF (“classic” BPF). New features such as maps and tail calls appeared. The JIT machines were rewritten. The new language is even closer to native machine language than cBPF was. And also, new attach points in the kernel have been created." [1]
[1]: https://qmonnet.github.io/whirl-offload/2016/09/01/dive-into...
It should be standard in Kali :)
Edit: then we changed it back because the Github page seems to have a shorter time-to-understanding. Preferences?