Wireshark VS Sysdig

Wireshark

A great way to test the effectiveness of a pinning implementation is by simulating an MITM attack. Tools like Mitmproxy or Wireshack allow us to create a test environment to monitor, intercept, and proxy network requests for a test host.

They even have a nice comment explaining the heuristic: https://github.com/wireshark/wireshark/blob/ef9c79ae81b00a63...

     * Heuristics to detect the WireGuard protocol:

FWIU, e.g. sysdig is justified atop whichever MAC system.

In the SELinux MAC system on RHEL and Debian, in /etc/config/selinux, you have SELINUXTYPE=minimal|targeted|mls. RHEL (CentOS and Rocky Linux) and Fedora have SELINUXTYPE=targeted out-of-the-box. The compiled rulesets in /etc/selinux/targeted are generated when

With e.g gnome-system-monitor on a machine with SELINUX=permissive|enforcing, you can right-click the column header in the process table to also display the 'Security context' column that's also visible with e.g. `ps -Z`. The stopdisablingselinux video is a good SELinux tutorial.

I'm out of date on Debian/Ubuntu's policy set, which could also probably almost just be sed'ed from the current RHEL policy set.

> * SELinux is deny by default, while in systemd you're playing whack-a-mole anyway, and are expected to add directives one by one until the application stops working. Unit logs usually make it obvious if something was denied.*

DENY if not unconfined is actually the out-of-the-box `targeted` config on RHEL and Fedora. For example, Firefox and Chrome currently run as unconfined processes. While decent browsers do do their own process sandboxing, SELinux and/or AppArmor and/or 'containers' with a shared X socket file (and drop-privs and setcap and cgroups and namespaces fwtw) are advisable atop really any process sandboxing?

Given that the task is to generate a hull of rules that allow for the observed computational workload to complete with least-privileges, if you enable like every rule and log every process hitting every rung on the way down while running integration tests that approximate the workload, you should end up with enough rule violations in the log to even dumbly generate a rule/policy set without the application developer's expertise around to advise on potential access violations to allow.

From https://github.com/draios/sysdig :

> "Sysdig instruments your physical and virtual machines at the OS level by installing into the Linux kernel and capturing system calls and other OS events. Sysdig also makes it possible to create trace files for system activity, similarly to what you can do for networks with tools like tcpdump and Wireshark.

Probably also worth mentioning: "[BETA] Auditing Sysdig Platform Activities"

DO offers metrics directly from the Dash, just sayin.

Also, https://github.com/draios/sysdig

fix(driver/bpf): exact check on bpf_probe_read_str() return value #1612

The positive aspect of the lockdown was that having unexpected free time came in really handy to look at a set of strange issues (896, 1610) users were experiencing for some months (~October 2019) while trying to get Falco to work fine on some Linux kernels (with the eBPF driver, clearly).