Hello everyone! Recently, I learned about the possibility of using a custom audit config with osquery - and it's cool! But in this case, we still become limited in monitored syscalls (execve/execveat/bind/connect). We would like to monitor other system calls as well. So, question: is it possible to create any UNIVERSAL table for the audit events, so that as many logs as possible can be parsed from the audit? For example: get syscall id/name and EXE/UID, that generate this syscall.

Audit is old news. If you are on Mac, use Endpoint Security and if on Linux use eBPF.

@Brian Bergstrand hi! eBPF today is not stable work in highload infrastructure. we tested eBPF in our machines and refused this method for monitoring syscalls, because eBPF often restarted/eat a lot of CPU/MEM . audit with custom configuration works very good, so i am interested in monitoring many syscalls

Hello everyone! I'm interested in this question too!

I’m interested in this too, as if there’s a native way then I’d love to use it! 👋 We’ve actually just built an extension to do exactly this. There are other syscalls we care about which are much lower volume than

execve

,

connect

, and friends. However, there did not appear to be a mechanism to do so in osquery directly - whether using kaudit nor eBPF. Although we could run another agent, and manage the audit rules manually, we’d need to then collect logs from a new audit daemon to get the new telemetry. Instead we settled on an osquery extension which installs bundled eBPF programs. These programs write data into a kernel managed ring-buffer, which is then “streamed” into an associated user-space ring-buffer which is flushed when the associated osquery table is queried. As a result, we can then just query the table as if it was a regular osquery table and get the new telemetry into our existing pipeline. (Although you mentioned issues with eBPF, these programs are very short, only use existing tracepoints for the syscalls we care about - which are “low volume”. We still use audit rules to get the rest of the high volume telemetry.)

So, the your solution is: for exec's and socket events you are using auditd rules format (for blacklisting/whitelisting of events). These events are written to osquery native tables. For collection purposes there are sql like queries. For other syscalls collection there is an extensions in ebpf. These events are written to native EBPF osquery table, isn't in?

That’s right. It’s not ideal, but we weren’t able to find another way to get arbitrary syscall data into some generic table in osquery like you were looking for 😞 The extension creates a set of new osquery tables, which when queried return the data from the user-space buffer which is populated by the data captured by the eBPF programs. The extension also handles loading of these eBPF programs. As a result, the data is query-able like a regular osquery table, so we can use osquery rules to get this new data. I’ve been pushing for us to open source this extension, so let me see what I can do about sharing the eBPF programs and any additional code samples here 🙂

Thanks a lot for your solution and research, Peter! Can you share a link to this PR? is it hard to add some new syscall's in these schema OR how hard is it? For example: we need to detect DirtyPipe exploitation attempt. For this purposes, i need to add the Splice syscall (275 syscall in x64 arch) with some filters (here is a link to research + auditd rules). With auditd this works perfect

Nope! However it does cover some of the stuff we care about 😆

Thanks a lot, Peter!

@Peter you are our hope. we will wait your extensions code (or code samples) on opensource

@Peter it will be wonderfull if you'll share it here, for testing purposes 😃

Absolutely, working on it. Will reply as soon as I can get the go-ahead 😄

i have some idea about resolve our problem: if we write extension, that will forward all other syscall except execve/connect from kernel to endpoint which will be set in the new flag? for example: in the kernel executed syscalls execve and splice osquery get EXECVE SYSCALL and add this row to the table process_events, and our extension get SPLICE SYSCALL and send this event to our endpoint log-aggregator Did someone tried this schema? Is there some issues or troubles?

The problem is that the audit socket can only be accessed by a single reader (which is why osquery with audit events active cannot work with auditd enabled).

This is well-known issue with netlink socket, WE are trying to use this socket with osquery to get other syscalls. I hope, that @Lili and @Peter will reach succsess!