We rewrote the Red Hand Collector in Rust. Not just to make it faster.

I've wanted to do this for years. And I'm particularly happy that we finally made it happen.

One of the more frustrating things about network monitoring is that you can see two machines communicating, capture the actual packets, identify the protocol, and still be missing one rather important detail: which process started the conversation?

Endpoint security tools can associate processes with network events, but they don't necessarily give you the actual packets. Network capture gives you the packets, but usually without the process context. Putting the two together has always been something of a holy grail for network visibility, especially if you want to do it without deploying another heavyweight agent, driver, or kernel module.

We've now rebuilt the Red Hand live Collector from scratch in Rust. It's a fairly substantial upgrade, and not just because Rust makes Python look bad in benchmarks (although it certainly didn't disappoint there).

Packets, processes, and the executable behind them

The new Collector captures packets directly from the network interfaces, then correlates connections with the processes responsible for them using native operating system information.

Our previous Python Collector already supported process attribution, but its accuracy suffered when connections were short-lived. Once a process closed its socket, there was often nothing left to associate with the traffic.

The Rust Collector is fast enough to make multiple attempts, including an early retry for connections that initially couldn't be attributed. It also limits how much CPU process lookups can consume, so a busy machine doesn't spend all its time trying to figure out who opened a socket.

The result? Around 99% of TCP connections attributed to their processes on Windows and macOS, and 97–100% of UDP flows in our tests.

We've also added executable fingerprinting, providing another layer of process identification and laying the groundwork for more advanced detections in future releases.

Ports are not protocols. Apparently we needed to say that.

Another major addition is protocol identification through deep packet inspection.

Instead of assuming that port 22 means SSH, port 443 means HTTPS, or port 3389 means RDP, the Collector inspects the actual traffic to identify the protocol.

It currently recognizes 101 protocols, including SSH, RDP, TLS, QUIC, SMB, database protocols, VPN tunnels, remote-access tools, and industrial protocols such as Modbus, S7, DNP3, BACnet and OPC UA.

It also extracts hostnames from traffic such as TLS, HTTP, NetBIOS and DHCP, helping identify devices and servers that might never appear in DNS logs.

This lays the groundwork for some detections I'm particularly looking forward to: SSH running over port 443, traffic on port 22 that isn't SSH, remote-access tools hiding behind web ports, and other cases where the actual protocol doesn't match what the port number suggests.

Those detections are coming in a future release.

The performance numbers are somewhat ridiculous

To see how far we'd come, we ran the old Python Collector and the new Rust Collector side by side on the same very busy Linux desktop, capturing the same traffic.

Here's one example of the difference:

That's x11 less CPU, nearly x6 less memory, and less than half the upload volume.

And the Rust Collector is doing more work, not less. It inspects packet payloads to identify protocols, fingerprints executables, and makes multiple attempts to attribute connections to processes.

Across our Windows, macOS and Linux deployments, the new Collector typically consumes around 1–3% of one CPU core and 12–40 MB of RAM.

I'm not going to pretend I expected quite that much of a difference.

One executable. No installation circus.

The old Python Collector was roughly 20 MB even when compressed. The new Rust Collector is a single 4–5 MB native executable, available for Windows, macOS and Linux.

No Python runtime, no packet capture driver, no kernel module, and no collection of dependencies to install. Run it directly or let it install itself as a background service.

We've also improved how the Collector chooses network interfaces, including VPN handling and native IPv6 capture support, and separated packet capture from process lookups and uploads. A slow process lookup no longer holds up packet capture. In our tests, the new capture pipeline reported zero dropped packets.

There's also built-in health reporting now, so we can see the Collector's CPU and memory usage, capture statistics, and processing health instead of guessing what happened on a machine we don't control.

Why I'm excited about this one

For me, this release is about closing the gap between two kinds of visibility that have historically been separated.

I want to see the real network traffic, not just events generated by whichever OS API a process happened to use. But I also want to know which process generated that traffic, which executable it came from, and what protocol it's actually using.

And I want to get that information without asking someone to spend half a day deploying an agent.

Combining packet capture with high-accuracy process attribution, executable fingerprints, and protocol inspection in a tiny, standalone Collector is a pretty big step forward.

It's also the foundation for quite a few things we've wanted to build into Red Hand for a long time.

This is probably the release I've been most eager to ship.

And yes, rewriting the whole thing in Rust was absolutely worth it.