A few weeks ago, we announced a new open source project called PacketStreamer, which provides a simple, lightweight, scalable technique for capturing and streaming packets from virtualized environments (K8s, VMs, AWS Fargate) and across multiple clouds. PacketStreamer has generated lots of buzz and garnered widespread support from the community. Today, we’d like to dive a bit deeper into some of the specific ways to use PacketStreamer.
The biggest driver for starting the PacketStreamer open source project was the desire to make threat hunting easier, especially for cloud native workloads. One of the best ways to identify threats is by observing network traffic, as it can reveal suspicious behaviors early on.
Modern compute environments are very different from the single Unix server assumptions that defined the design of legacy packet capture tools. Modern environments are cloud-based or distributed across many servers, meaning that packet capture must support centralized capture across distributed and elastic endpoints. They also may use virtualization technologies that limit access to the host and kernel, meaning that packet capture must be deployed via containers and DaemonSets.
PacketStreamer is the network capture solution for modern, cloud native environments. It captures traffic from large numbers of remote servers (for example, cloud nodes) and streams it to a centralized location. It supports modern stacks, such as Kubernetes (via a DaemonSet), Docker, and AWS Fargate, as well as standard hosts.
PacketStreamer creates efficiency by livestreaming the network traffic that an application receives to a different server – either on the cloud or a different system altogether. Essentially, it acts as a mirror, providing an exact replica of the traffic going into the application. From there, users can perform live analysis with their tool of choice. PacketStreamer is not an inline tool and therefore does not add any latency to the application while simultaneously enabling continuous monitoring of all the network traffic that comes to that application for any bad actors or malicious activity.
PacketStreamer can be used with any traffic analyzer and it can mirror as much traffic as the system on which it operates can handle, so it’s a great option for many organizations.
Security teams typically engage in post-facto traffic analysis following a security event. Traditionally, this means saving the traffic locally on the system where the application is running, extracting the file out of that system, and analyzing it at a later time. PacketStreamer simplifies this multi-step process by remotely saving the network traffic, thereby eliminating the additional steps of saving it locally, extracting the file, checking disc space, etc.
Users have the ability to remotely save the file to the location of their choice, and new remote save locations are added regularly. For example, we are particularly grateful that a member of the PacketStreamer community contributed to the project by adding a way to save to an Amazon S3 bucket.
While we built PacketStreamer to help the community enhance their security posture, we’re delighted that community members have found even more ways to use it. For example, we’ve heard from users that they find it helpful for debugging intermittent issues. It makes sense that PacketStreamer can help surface errors when log files aren’t detailed enough. By gathering network traffic in PacketStreamer, users can see the requests processed by a server to help pinpoint the root cause.
Whether you use PacketStreamer for threat hunting, forensics, or another use case altogether, we want to hear about it. Join us on Slack to ask questions and get answers, or just follow along with the conversation.
If you haven’t yet tried PacketStreamer, you can find it on GitHub.
.png)
