Security on The Official Wireshark Blog

From Network Packets to Log Data: How Logray built upon Falco’s foundation

Mon, 29 Jan 2024 17:13:42 +0000

In the ever-evolving landscape of network security, a new star has emerged – Logray. The name comes from “log” (as in event logs) and “ray” (the closest zoological cousin to sharks, similar to “wire” and “shark” for network packets. Logray represents a significant leap in network security tools. Premiering at SharkFest ’22, it takes the best of Wireshark and innovates further by focusing on log data analysis. While Wireshark focuses on scrutinizing network traffic, Logray delves into system calls, Amazon Cloudtrail logs, and other log data, offering new vistas for network security professionals.

At its core, Logray retains the user-friendly aspects of Wireshark, including the familiar filter engine, intuitive colouring, and context menus. Yet, it goes beyond by accommodating the reading of PcapNG files embedded with log data and facilitating the integration of third-party plugins using Falco’s powerful plugin API. System call and log data is saved using the PCAP Next Generation Dump File Format (pcapng), which provides a powerful and versatile shared foundation which broadens the scope of data capture and analysis.

A notable innovation within Logray is ‘falcodump‘, a component enabling the dumping of log data via a Falco source plugin. As an external capture (extcap) tool, falcodump captures log messages from cloud providers, presenting each plugin as a distinct interface.

For instance, the below command is run under the hood to capture AWS CloudTrail events from an S3 bucket. The end user does not have to type it themselves.

falcodump --extcap-interface=cloudtrail --fifo=/tmp/cloudtrail.pcap --plugin-source=s3://aws-cloudtrail-logs…/CloudTrail/us-east-2/… --capture

Logray’s choice to support Falco plugins allows security practitioners to harness the falcodump capabilities to potentially bridge the gap between sporadic data sources such as cloud services and identity providers.

The true value of Logray lies in its ability to synthesise information from system calls and log data into a unified recording format. This cohesive approach offers analysts a panoramic view of relevant events, transcending the limitations of examining network, system, and log contexts in isolation or through disjointed SIEM tooling. Logray embodies a holistic solution, using the power of Falco to enrich data from otherwise disjointed event sources, providing profound contextual analysis for system introspection.

In conclusion, Logray isn’t just another tool; it’s a paradigm shift in network security, enabling professionals to connect the dots across multiple data sources seamlessly. This unified vision provides a clearer, more comprehensive understanding of security events, marking a significant advancement in the field of network security analysis.

The evolution of system introspection from BPF to Wireshark to Falco

Wed, 27 Sep 2023 15:14:02 +0000

Falco, an open source innovation, was conceived with the vision of crafting a flexible and robust rules engine atop the Sysdig libraries. This initiative aimed to furnish a potent tool for the detection of aberrant behaviors and intrusions within modern applications, akin to the Snort paradigm but tailored to the realm of system calls and finely tuned for cloud environments.

Nevertheless, it’s important to recognize that Falco and Wireshark represent distinct facets of this evolutionary process. Falco offers ongoing surveillance akin to Snort, while Wireshark specializes in interactive endpoint network traffic analysis.

Introduction 🔗

Part of this journey has been the emergence of cloud-native apps. From the early days of BPF (Berkley Packet Filter) and libpcap (a portable C/C++ library for network traffic capture), which laid the foundation for network packet analysis, to the familiar graphical user interface of Wireshark, our understanding of network data has undergone profound changes. This article embarks on a journey through this transformation, shedding light on how tcpdump and libpcap sparked an explosion of packet-based analysis and runtime security tools exemplified by Wireshark and Snort.

Wireshark, Snort, Nmap, Kismet, ngrep, and a bunch of other tools started at around the same time and are all evolutionary branches of tcpdump and libpcap.

However, as cloud computing continues to reshape the technological landscape, traditional network packet analysis tools have found themselves grappling with an evolving challenge: the cloud itself. Cloud-native applications have ushered in a new era of complexity and dynamism, rendering many existing visibility solutions obsolete. This shift necessitated a fresh perspective on network monitoring, leading to the birth of Falco, a tool poised to be the Snort of the cloud.

In this exploration, we’ll dive into the why and how of Falco’s creation, uncovering the critical role it plays in addressing the challenges of cloud-native applications from the evolution of network packet analysis to the rise of Falco as a powerful solution for Linux workloads, whether they be hosts, containers, or IoT devices. Join us on a journey through the ever-changing landscape of network analysis and security in the cloud.

Starting the story with Network Packet Analysis 🔗

During the late 1990s Internet boom, the demand for computer networks skyrocketed, leading to an increased need for monitoring, troubleshooting, and securing these networks. Regrettably, the available network visibility tools of that era were prohibitively expensive for many operators, leaving them grappling with a lack of insights.

Consequently, teams worldwide embarked on a mission to address this predicament. Their efforts revolved around expanding existing operating systems to incorporate packet capture capabilities, essentially transforming off-the-shelf computer workstations into devices capable of residing on a network and capturing all inbound and outbound data packets from other workstations. One such solution was the Berkeley Packet Filter (BPF), crafted to extend the functionality of the BSD (Berkeley Software Distribution) operating system kernel.

For Linux users, the term ‘eBPF’ may ring a bell – a virtual machine renowned for securely executing arbitrary code within the Linux kernel. Remarkably, eBPF has evolved into a powerful and flexible technology over the years. However, its origins trace back to a modest programmable packet capture and filtering module designed for BSD Unix.

The BPF team introduced a game-changing library known as ‘libpcap,’ which enabled any program to capture raw network packets. It was developed in order to make tcpdump more useful. For instance, it gave the ability to filter packets. Since then, a bunch of spin-off networking projects would emerge on the scene. In 1998, a GUI-based open source protocol analyzer named ‘Ethereal’ (later renamed Wireshark) was introduced, eventually becoming the gold standard in packet analysis that persists to this day.

What unites ‘tcpdump,’ Wireshark, and numerous other popular networking tools is their ability to access a data source that is rich, accurate, and reliable, all collected in a nonintrusive manner: raw network packets. This fundamental concept will be central to our discussion moving forward.

The evolution of Packet-Based Intrusion Detection Systems 🔗

Introspection tools, such as tcpdump and Wireshark, naturally emerged as the initial applications harnessing the capabilities of the BPF packet capture stack. However, as time progressed, innovative applications for packet data began to surface. Enter Snort, an open source, packet-based runtime security tool that shares common ground with Falco. Much like Falco, Snort operates as a rule engine, processing packets acquired from network traffic. Like its cloud-native counterpart, Snort boasts an extensive library of pre-configured rules designed to identify threats and unwarranted activities by scrutinizing packet content, protocols, and payload data. The success of Snort served as a catalyst for the development of similar tools, including Suricata and Zeek.

What truly empowers tools like Snort is their proficiency in assessing the security of networks and applications in real time, even as these applications run. This real-time focus proves invaluable by delivering immediate protection with a unique emphasis on runtime behavior, enabling the detection of threats rooted in vulnerabilities that may remain undisclosed.

The issue with Network Packet Capture in the Cloud 🔗

The utilization of network packets as a foundational data source has spawned a thriving ecosystem. Nonetheless, several emerging trends have gradually eroded the viability of packets as an unequivocal source of information.

First, the task of comprehensively collecting packets has grown increasingly complex, especially within environments such as the cloud, where access to routers and network infrastructure is constrained. Second, the proliferation of encryption and network virtualization has posed formidable challenges in extracting valuable insights from network traffic. Lastly, the ascent of containerization and orchestrators like Kubernetes has rendered infrastructures more elastic while concurrently complicating the reliable collection of network data.

Once again, a dynamic new ecosystem was unfolding, yet the means to effectively troubleshoot and secure it remained elusive.

Solving these shortcomings with system calls 🔗

Before the emergence of Falco, an open source tool known as ‘Sysdig Inspect’ was crafted with a primary focus on the collection of packet data within cloud-native ecosystems. This was achieved through the capture of system calls, often referred to as syscalls, originating from the kernel of the operating system.

Syscalls, as a data source, offer a richness that surpasses that of mere network packets. They encompass a wide spectrum of activities, extending beyond network data to encompass file I/O operations, command executions, interprocess communication, and more. Syscalls stand out as an ideal data source for cloud-native environments as they can be harnessed from the kernel, catering to both containerized environments and cloud instances. Moreover, the process of collecting syscalls is characterized by its simplicity, efficiency, and non-invasiveness.

The architecture of Sysdig comprised a kernel capture probe, making use of either the default, loadable kernel module or leveraging eBPF. To facilitate the development of capture programs, Sysdig offered a suite of libraries, enabling seamless integration with modern cloud-native technologies such as Kubernetes and various orchestrators. This versatility addressed the shortcomings observed in environments where traditional solutions like Snort and Wireshark fell short. Additionally, Sysdig provided a command-line tool replete with decoding and filtering functionalities, tailored to accommodate the prevalent network packet workflows essential in cloud environments, where the ease of filtering and scriptability of trace files is paramount.

Bringing us to Falco – the evolution of Wireshark to the Cloud 🔗

DDrawing from our comprehension of how Snort introduced a rule-based engine for scrutinizing network traffic to identify suspicious activity, an evolution that implemented Wireshark’s network introspection, and how Sysdig expanded the scope of visibility within cloud-native environments by delving into system calls, effectively departing from sole reliance on Wireshark’s libpcap framework. It logically followed that an Intrusion Detection System (IDS) solution would emerge, featuring a sophisticated rule-based engine tailored for cloud-native workloads while harnessing the capabilities of eBPF and the kernel’s system call architecture.

Falco’s rule engine drew inspiration from Snort’s design but operated within a far more expansive and versatile dataset, seamlessly integrated with the Sysdig libraries. While its default ruleset may be more concise than Snort’s, Falco empowers users to craft intricate rules that trigger in real-time based on arbitrary contextual factors. These factors encompass a wide array of scenarios, including access to sensitive data, mode transitions, unexpected network connections, socket alterations, compliance breaches, and more. Given its capacity to monitor all activities on a server or node through system calls, Falco functions as a real-time intrusion detection tool, mirroring Wireshark’s role in providing real-time network analysis for endpoints.

Conclusion 🔗

In the journey from the early days of BPF to the widespread adoption of Wireshark, we’ve witnessed the remarkable evolution of system introspection tools, each one contributing to the ever-expanding landscape of cybersecurity. However, as cloud-native computing and microservices architectures become the new norm, a new champion has emerged: Falco. Falco represents the cutting edge of intrusion detection, specifically designed to tackle the intricacies and challenges posed by cloud-native hosts and workloads. With its real-time behavioral monitoring, container awareness, and comprehensive rule sets, Falco stands as a testament to the adaptability and innovation in the world of cybersecurity. As the digital landscape continues to evolve, Falco is the tool of choice for those who prioritize the security and integrity of their cloud-native environments. It’s not just a system introspection tool; it’s the future of protecting what matters most in this rapidly changing world of technology.

The Cloudflare Incident And Its Impact On Wireshark.org

Sat, 25 Feb 2017 18:39:29 +0000

Cloudflare recently announced a security incident that potentially impacts anyone who visited various wireshark.org and winpcap.org sites for the past six months.

What happened? 🔗

Cloudflare is a popular service that provides content delivery, DDoS protection and DNS services for web sites.

A software bug Cloudflare’s servers leaked potentially sensitive information. Some of that information ended up in caches all over the Internet. At Google, Microsoft, your ISP, your company’s or university’s proxy servers, and elsewhere. Due to the randomness and distributed nature of the bug, it’s difficult to know what the full impact is. Cloudflare provides the following estimate:

“The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (thatâ€™s about 0.00003% of requests).”

The bug was introduced on September 22, 2016 and fixed on February 18th, 2017.

The Google Project Zero bug describing the issue in detail can be found at https://bugs.chromium.org/p/project-zero/issues/detail?id=1139

Cloudflare’s incident report can be found at https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/

The initial Hacker News discussion can be found at https://news.ycombinator.com/item?id=13718752

Was Wireshark affected? 🔗

The following wireshark.org and winpcap.org sites were behind Cloudflare proxies during the period in question:

ask.wirehsark.org
blog.wireshark.org
bugs.wireshark.org
sharkfest.wireshark.org
sharkfesteurope.wireshark.org
wiki.wireshark.org
www.wireshark.org
www.winpcap.org

Wireshark’s download servers (*.dl.wireshark.org), buildbot.wireshark.org and code.wireshark.org were not behind Cloudflare.

I browsed to a one of the sites listed above between September 22nd, 2016 and February 18th, 2017. Am I affected? 🔗

The chances are slim, but those chances are not zero.

Most of the content that we serve is “static” and “public.” That is, it’s the same for everyone and doesn’t contain any sensitive information. The risk exposed by Cloudflare is from dynamic content that contains sensitive information such as the login page on ask, bugs, wiki, etc. Our web sites get frequent requests for static content, but dynamic requests are relatively infrequent.

In a world where everyone has infinite free time I would have no qualms about recommending that everyone with a wireshark.org account change his or her passwords. However, this is the real world and your time is valuable. If you logged in to one of our sites and used a unique password it might not be worth your time to change it. On the other hand, if your professional reputation depends on your ask.wireshark.org score you probably should. If you have any sort of administrative access you definitely should. Most of our users fall into the first category.

If you’re wondering why it looks like I’m downplaying the importance of changing your wireshark.org passwords, see the next question.

I used a web browser, smart phone, or an internet-connected wearable doohickey between September 22nd, 2016 and February 18th, 2017. Am I affected? 🔗

I honestly don’t know. The chances are almost certainly not zero.

Cloudflare is a very popular service. At the time of this writing an unofficial list of affected sites stands at more than four million entries and counting. It includes many of the world’s most popular web sites.

If you’re going to spend time changing passwords, doing so for sites that deal with finance, email, DNA testing, dating, and other parts of your personal life probably ranks higher than that for, say, the Wireshark wiki.

Isn’t a vague answer like “the chances are slim but not zero” a frustratingly craptastic one compared to a definitive “yes” or “no”? 🔗

Yes, but it’s also the honest and correct one.

Update: March 2, 2017 🔗

Yesterday Cloudflare posted an update on the issue at https://blog.cloudflare.com/quantifying-the-impact-of-cloudbleed/. In it they posted the following leak estimates:

 Requests per Month       Anticipated Leaks
 ------------------       -----------------
        200B â€“ 300B         22,356 â€“ 33,534
        100B â€“ 200B         11,427 â€“ 22,356
         50B â€“ 100B          5,962 â€“ 11,427
          10B â€“ 50B           1,118 â€“ 5,926
           1B â€“ 10B             112 â€“ 1,118
          500M â€“ 1B                56 â€“ 112
        250M â€“ 500M                 25 â€“ 56
        100M â€“ 250M                 11 â€“ 25
         50M â€“ 100M                  6 â€“ 11
          10M â€“ 50M                   1 â€“ 6
              < 10M                     < 1

The affected wireshark.org web sites get just over 10M requests per month combined. Private traffic is substantially less than that.

Comments 🔗

Comment by Graham Bloice on 2017-02-27 04:12:48 +0000 🔗

And the implications if using a remote authentication service rather than a password held on a Wireshark service, e.g. OAuth?

Comment by Greg Gill on 2017-03-04 13:10:47 +0000 🔗

Not a good news at all.
“I browsed to a one of the sites listed above between September 22nd, 2016 and February 18th, 2017. Am I affected? The chances are slim, but those chances are not zero”

Comment by Dustin DeTorres on 2017-03-23 04:48:57 +0000 🔗

Is there anything a user should do?

Detecting Heartbleed Traffic

Wed, 09 Apr 2014 23:02:49 +0000

The big news in the tech industry this week is The Heartbleed Bug, a vulnerability that affects a large portion of secure web sites on the Internet. I updated the Wireshark and WinPcap web sites on Monday (along with reissuing and revoking certificates) shortly after OS patches were released.

Our web sites are protected going forward, but what about the past? We have a Shark appliance in our environment but that leads to a challenge. We had about 350 GB of HTTPS on our network on Monday alone. This is just slightly too large to load into Wireshark.

Fortunately one of my coworkers (P.J. Malloy) came up with a BPF filter that matches Heartbleed traffic:

http://www.riverbed.com/blogs/Retroactively-detecting-a-prior-Heartbleed-exploitation-from-stored-packets-using-a-BPF-expression.html

Applying this filter directly on the Shark appliance gave me a much smaller number of packets which I could easily analyze in Wireshark. So far I haven’t found anything suspicious.

Used Cars and Stub Installers

Tue, 06 Dec 2011 19:59:28 +0000

The Wireshark development team works hard to earn the respect of our users. This includes making sure that downloading and installing Wireshark is as easy and trouble-free as possible. Right now the vast majority of our users can go to www.wireshark.org, follow the big green arrows, and immediately download the appropriate Wireshark package for their platform.

For many years a number of third party sites have also offered Wireshark downloads. Typing “wireshark download” into your favorite search engine will turn up a bunch of them, usually just below links to wireshark.org. These sites are popular and often provide valuable services such as reviews and malware prescreening. They also reside outside the Wireshark ecosystem — we don’t link to them and aren’t affiliated with any of them.

"This is the Cadillac of invasive toolbars at a Chevy price!"

Sometimes these sites abuse their relationship with their users. For example a few months ago Download.com started using a stub installer which tries to get you to install various toolbars and who-knows-what-else before it installs the package you ultimately want, much like a sleazy car salesman trying to bundle add-ons you don’t want or need.

This sort of bottom-feeding behavior is harmful to our user community and exploits the goodwill we have with our users. Brian Krebs and Gordon “Fyodor” Lyon describe the problem with much more depth and eloquence than I can.

I sent a request to Download.com to disable their stub installer for Wireshark. They complied, but there are dozens of other download sites. Trying to keep tabs on all of them would result in a never-ending game of Whac-A-Mole®.

On behalf of the Wireshark development team I promise to provide easily accessible, direct downloads of Wireshark from wireshark.org just as we always have. If you choose to download Wireshark somewhere else we can’t guarantee that the experience will be free of shenanigans so please be careful.

Comments 🔗

Comment by Sean B on 2011-12-07 01:36:37 +0000 🔗

But they just wanted to ‘wrap’ all these nice programs in an extra little blanket for…warmth, and safe-keeping…and stuff. I mean who notices extra toolbars and new default search engines? Intrusive? Infuriating? Nonsense.

Running Wireshark as You

Thu, 04 Feb 2010 20:11:57 +0000

Running Wireshark on Linux involves an interesting challenge¹: Capturing packets requires root access, but Wireshark is big program and we strongly recommend against running it with elevated privileges. On Linux it’s common to see Wireshark running as root, but this is nearly unheard for similarly-sized applications like Firefox and GIMP. How can we avoid running Wireshark as root?

UPDATE 2010-02-10: Made changes suggested by Jaap and Balint.

A good way 🔗

Notice how I said “capturing packets requires root” above? Here’s a secret — Wireshark doesn’t capture packets. A separate program called dumpcap does. Compared to Wireshark, dumpcap is tiny. It’s much less complex and much safer to run as root. We can make it so that dumpcap runs as root and that only users in a particular group can run it:

$ sudo -s
# groupadd -g wireshark
# usermod -a -G wireshark gerald
# chgrp wireshark /usr/bin/dumpcap
# chmod 4750 /usr/bin/dumpcap

A better way 🔗

It’s also possible to let dumpcap do its job without involving root access at all. For a very long time Linux has allowed the use of fine-grained permissions called capabilities. In many recent distributions you can use the setcap utility to add capabilities to individual files.

Dumpcap needs CAP_NET_RAW and CAP_NET_ADMIN, so what do we need to feed setcap? On my Ubuntu Karmic system the setcap man page points you to cap_from_text. Cap_from_text points you to _cap_names, an array in the kernel. It would be nice if the setcap man page included a list of capability names along with a few examples. As it turns out, the names need to be in lower-case.

$ sudo -s
# sudo apt-get install libcap2-bin
# groupadd -g wireshark
# usermod -a -G wireshark gerald
# chmod 750 /usr/bin/dumpcap
# setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap

You can also set these capabilities for Wireshark and TShark directly. Fully-functional filesystem capabilities is something the Linux world has needed for a very long time. I’m glad they’re finally seeing wide deployment.

Who’s Doing This? 🔗

Debian and Gentoo are using group-based permissions for Wireshark. Ubuntu is working on it. Hopefully the other distributions will follow suit.

1. This is a problem on other systems too, but it’s usually easier to solve. On Windows you can run the NPF service at startup. On OS X you can use ChmodBPF.

Comments 🔗

Comment by Jake on 2010-02-08 05:45:00 +0000 🔗

Note that the recent Debian packages already implement this, something you’ll notice when installing them. Thanks Balint. For Ubuntu it’s still on Wishlist status.

Comment by Balint on 2010-02-10 04:11:39 +0000 🔗

Gerald,
Could you please suggest using the wireshark system group instead of packetcapture?
Gentoo and Debian already use wireshark group, and it would be easier for newcomers to use the same group name everywhere.

I plan to update the Debian packages to use setcap, thanks for the hint.

Comment by Gerald Combs on 2010-02-10 10:59:09 +0000 🔗

I changed the example group to “wireshark” and mentioned Gentoo, Debian, and Ubuntu.

Comment by Balint on 2010-02-17 10:28:51 +0000 🔗

It would also make sense to use groupadd -g -r wireshark instead of groupadd -g wireshark to make the new group a system group. That would match and nicely coexist with Debian’s and Ubuntu’s installation method.

Using Wireshark to track a botnet

Wed, 28 Oct 2009 19:05:19 +0000

Security researchers have written a Wireshark dissector that will decrypt the command and control protocol used by the Mariposa botnet. More information at Palo Alto Networks and Defence Intelligence.

Comments 🔗

Comment by ManOnFire on 2009-11-02 08:05:48 +0000 🔗

Anyone have a packet capture for mariposa C&C? I would like to test the decryption plugin. Thanks!

Comment by Gerald Combs on 2009-11-04 13:47:55 +0000 🔗

You might try contacting Palo Alto Networks or Defence Intelligence. I don’t see any capture file downloads on either site.

Tip from Laura: SMB2 Vulnerability Wireshark Filter

Tue, 08 Sep 2009 20:38:19 +0000

The big tech news this morning was a recently-discovered SMB2 vulnerability in Windows Vista, 2008, and 7. Laura Chappell created a Wireshark display filter for identifying offending traffic:

((smb.cmd == 0x72) && (smb.flags.response == 0)) && !(smb.pid.high == 0)

See the full report on her site for more information.

Comments 🔗

Comment by Jay on 2009-10-07 14:19:26 +0000 🔗

Hi,
I am doing some Software Performance Test(thru network environment) and Im using Wireshark to analyze it.
My Capture filter is ether host xx:xx:xx and Display filter is smb2.
What is the filter syntax should I use to remove the packet using GUID handle file:xxx under smb2 protocol.
Please help.