boopkit

> What's the performance hit for doing this? So I want to be clear. This work is very much in the "fantasy" stage. I haven't ran this at scale, and there is a lot I would do before I blindly rolled something like this out. As far performance impact, it obviously would depend on how it's implemented however I think a reasonable amount of "tracer packets" being sent out every 15 seconds or so to each hop shouldn't be too disruptive to the network, or to the host machine issuing the request. In other words if you take the `ptrace(2)` concern out of the equation (this is the big one in my mind) its going to be negligible. > And, the rootkit question, how would eBPF notice you doing this? I suppose it would depend on what your strategy with eBPF is and where you were looking. Reminding yourself that the pidfd_getfd and pidfd_open functions are

This is a good write-up and I like the diagrams. What appears to still be notably missing from eBPF is an "off switch". AFAIK there are still no kernel boot time commands [0] to disable eBPF entirely. I have to recompile the kernel to disable it and it is known that most people will not do this. eBPF has the potential for file-less malware to run hidden from detection and I foresee the ability to tickle ring -3 (and -4?) CPU within CPU functions while bypassing local firewalls. Here is some example code of what people already know how to do today and this list will grow as people discover more capabilities. [1][2][3][4][5][6] These do require some privileges to insert but will remain running and hidden until reboot. Privilege escalation today is easier than ever with the growing misuse and poor configurations of sudo as well as the g