Are there any plans to add DNS requests monitoring table for Linux ?

Not much so far other than a couple of experiments 1. hooking getaddrinfo with bpf: https://asciinema.org/a/302647 2. hooking into systemd-resolved, also with bpf: https://github.com/trailofbits/ebpfpub/blob/main/examples/systemd_resolved/src/main.cpp (method found by @Artemis Tosini)

@alessandrogario Thanks alot. Where can I get code for first example ? Do you know why it wasn't adopted, that's a huge deal for DAG domains and known malware C2 detection

I never upstreamed these changes to osquery, because DNS monitoring is complex

Understood, yeah malware might never use these

Additionally, any program that does not use DNS primitives we are hooking into and connect directly to a DNS server will also bypass it

BTW is it possible to implement this using libpcap ?

Well not necessarely, for example a dropper could reference those

I thought about something as simple as possible and not so obvious to bypass

Is it still compatible to modern osquery ?

In summary: 1. I think we could have a dns events table that attempts to trace multiple sources. One source could catch something that another one can't 2. DNS over HTTPS: the only hope is to trace the runtime but we are subject to the usual problems (a binary could not be using that specific code) 3. Packet inspection (at this level) is not great, those libraries really are not that much tested (PcapPlusPlus). TCP reassembly is hard and needs to be erwritten from scratch in a secure way

IMO this network_monitor of yours looks very promising, it definitely should cover droppers, rather simple malware, and hopefully dangerous ones on bootstrap stage

I've been looking into alternatives ever since the network_monitor extension, but never really started working on something new (other than those tiny/simple BPF examples)

such table would've been super useful in detection of DGA domains

It is marked as experimental as we don't fully trust the third party code we are using; while it drops the privileges, the packet parser is still processing unstrusted input from the network

Thank. How do you think, are there any chances of implementing this table in future? Because although I see huge benefits in this, I don't know if anyone else is interested

my personal opinion is that it should use a different approach; i don't know if anyone is going to implement in the future

understood thanks alot for your time and efforts

My last project is this one: https://github.com/osquery/osquery/pull/7773 If you happen to be using bpf_process_events, this replacement is way faster and uses significantly less CPU and memory

I'm heavily relying on bpf_socket_events

We could all look at DNS events again, but will only be notes for now and not an ETA for the implementation

So am'I right assuming that I can use bpf_process_events instead of bpf_socket_events, to get remote_address?

No, that PR I linked only implements bpf_process_events_v2, there is no bpf_socket_events_v2 yet

For my purposes I need either SHA256 or remote_address in cases where it's possible

But you'll be able to do the switch to it in the future when sockets events are added to the new implementation

Thanks, I have no CI account, so I'll just wait on this

The GitHub account is enough, I thikn we also have uploaded them in the #ebpf channel

I'm mostly interested in capabilities that enable behavioral analysis. So anything related to procfs, DNS requests monitoring are huge selling points to me 🙂

I think it's mostly a matter of funding

Last quick question. Do you know if there's any way to route osquery logs to unix socket without writing your own logger plugin ?

not really sure, you could ask in #linux

Thanks

You’re not totally alone, but somewhat it feels hard to get that data in a way that fits with osquery. When pcap has come up in the past, the PRs have generally felt insecure — they did stream reconstruction in privileged osquery space. They forced the NIC into promiscuous mode. Etc. Alessandro’s BPF work is good, and I would point at him as the expert here.

Would there be any issue from the TSC regarding in-core DNS monitoring functionality?

Last quick question. Do you know if there’s any way to route osquery logs to unix socket without writing your own logger plugin ?

Not sure. Does it work if you point the logger path at the socket, or is it fussy about it not being a plain file? Otherwise, probably plugin terratory. Wouldn’t be a hard one though

I already wrote a plugin and it works, so I'm just checking if it was necessary

Would there be any issue from the TSC regarding in-core DNS monitoring functionality?

I mean, what do you think? 😄 My initial feeling is that it might be okay, but we should think about how to disable it. The biggest issue with that old ja3 plugin was that it felt insolvably insecure, not that we were opposed theoretically.

that was relevant for pcap based functionality as I understood

Yeah i don't think we should use packet capture, it's too much of a problem - we would have to come up with a BPF solution for it