[Gerald Combs <gerald@xxxxxxxxxxxxx>]

On 2/6/25 7:20 AM, Martin Mathieson via Wireshark-dev wrote:
> Hi,
>
> Given enough time I could find all of this out for myself, but I'd like to check my understanding of how things fit together, if someone could indulge me?  I've only downloaded a couple of Windows builds so far.
>
> Trying out some captures, and enabling View | Reload as File Format | Capture, it looks as though 'Sysdig Machine Info Block' is fairly similar to 'enhanced packet block', though unfortunately 'Dissect next layer' doesn't do anything yet.
>
> The data visible in the bytes pane is much less than the data block and only corresponds to the Sysdig Event.  What is the rest of the data?

The rest of the data is in preceding machine info, interface list, user list, process list, and file descriptor list blocks. The Falco bridge dissector currently opens the capture and processes it in parallel using libsinsp, which parses enriched event data for us. We might want to parse the various info blocks ourselves at some point, but that will require a fair amount of effort. The code that reads and writes each block can be found in userspace/libscap/engine/savefile/scap_savefile.c and userspace/libscap/scap_savefile.c in the falcosecurity/libs repository.

> Where a frame has Event Information, is this info enriched by libsinp?  Is that done entirely at the time of capture? Or does some of the info here come from the dissector e.g., looking up the timestamps of related event frames?

That's correct. The Event Information, Process Information, File Descriptor Information, and most other top-level items come from libsinsp (see line 1377 in packet-falco-bridge.c for a complete list). It's collected at the time of capture and stored in metadata blocks. The Process Ancestors tree information is an exception and is tracked inside the Falco bridge dissector.

> Similarly, are the Event Arguments and Process Information already in the event data?  Are they perhaps parsed by their own libraries into structs, making it difficult to show which bytes each value fromes from?  I suppose I am used to the idea that you can click on any non-generated field and see exactly where it came from.

The event arguments are in the event data and are highlighted by the Sysdig Event dissector. They're also provided by libsinsp, but in that case we don't have size or offsets. I'm not sure if we should omit one in favor of the other since they're both potentially useful; the Sysdig Event tree gives us highlighting and the Event Arguments tree gives us better information, e.g. "ETIMEDOUT" instead of "-110".

At one point I tried marking each libsinsp enriched field as generated, but that resulted in a distracting amount of square brackets.

> If Falco is like an IDS, are we dissecting alerts output from when rules match, or just generating filters that are equivalent to falco rules?  Would it ever make sense to have the falco equivalent of the snort post-dissector that shows the context and details of detected anomalies against some rule set?

We include the libraries that Falco and the sysdig CLI tool use to capture events, but we don't include Falco itself. There's nothing stopping us from including Falco however, and being able to match an event with a Falco rule sounds like it would be useful.

> If we see some anti-pattern in events we'd like to detect in the future, how would we teach Stratoshark to do that?  Would we hand-code it in sysdig or falco dissectors, or create a new falco rule for it?  And put it in a local profile?  Is there the falco equivalent of the emerging-threats rules?

There's a rules repository at https://github.com/falcosecurity/rules. We might be able to pull from that.

> Anyway, the first thing I would like to do with Stratoshark is to sanity-check Wireshark starting up and shutting down.  At least we should see the file reads/writes we do, and look into anything fishy.
>
> Any help would be appreciated.  Thanks,
> Martin
>
>
> _______________________________________________
> Wireshark-dev mailing list -- wireshark-dev@xxxxxxxxxxxxx
> To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx