https://github.com/osquery/osquery logo
#general
Title
# general
s

slevchenko

11/14/2022, 9:57 AM
Are there any plans to add DNS requests monitoring table for Linux ?
a

alessandrogario

11/14/2022, 12:57 PM
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)
s

slevchenko

11/14/2022, 1:00 PM
@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
a

alessandrogario

11/14/2022, 1:22 PM
I never upstreamed these changes to osquery, because DNS monitoring is complex
In the first example, I'm hooking the glibc .so on disk; if a program is not using that library on disk then it won't trigger our probes. Example: other binaries within a container, golang programs (they don't use glibc), etc
In the second example, I'm hooking into the systemd DNS service; any program that will not use it will not trigger any event
s

slevchenko

11/14/2022, 1:24 PM
Understood, yeah malware might never use these
a

alessandrogario

11/14/2022, 1:24 PM
Additionally, any program that does not use DNS primitives we are hooking into and connect directly to a DNS server will also bypass it
s

slevchenko

11/14/2022, 1:24 PM
BTW is it possible to implement this using libpcap ?
a

alessandrogario

11/14/2022, 1:25 PM
Well not necessarely, for example a dropper could reference those
Yes, I have built something with that in our extensions repository
However, that will not cover DNS over HTTPS and it's kind of just test code at this point
s

slevchenko

11/14/2022, 1:25 PM
I thought about something as simple as possible and not so obvious to bypass
s

slevchenko

11/14/2022, 1:26 PM
Is it still compatible to modern osquery ?
a

alessandrogario

11/14/2022, 1:29 PM
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
A mix could be made to replace libpcap with BPF, but the performance implications need to be checked
(yes the extension should work fine with the latest osquery)
s

slevchenko

11/14/2022, 1:30 PM
IMO this network_monitor of yours looks very promising, it definitely should cover droppers, rather simple malware, and hopefully dangerous ones on bootstrap stage
a

alessandrogario

11/14/2022, 1:31 PM
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)
s

slevchenko

11/14/2022, 1:32 PM
such table would've been super useful in detection of DGA domains
Thanks alot
a

alessandrogario

11/14/2022, 1:37 PM
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
It was also not updated in a while and there may be updates and security fixes in the libraries that it uses
s

slevchenko

11/14/2022, 1:42 PM
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
a

alessandrogario

11/14/2022, 1:47 PM
my personal opinion is that it should use a different approach; i don't know if anyone is going to implement in the future
I occasionally look at these problems again in the future, but it's really mostly a spare time project at this point
s

slevchenko

11/14/2022, 1:48 PM
understood thanks alot for your time and efforts
a

alessandrogario

11/14/2022, 1:48 PM
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 may extend this PR in the future to include network events too (which, compared to the bpf_socket_events we have right now, will always have both local ip:port and remote ip:port for all events)
(also, it is more reliable in how binary paths are acquired)
s

slevchenko

11/14/2022, 1:50 PM
I'm heavily relying on bpf_socket_events
So I can replace them with bpf_process_events ?
a

alessandrogario

11/14/2022, 1:50 PM
We could all look at DNS events again, but will only be notes for now and not an ETA for the implementation
socket events are not yet implemented in that PR 😞
s

slevchenko

11/14/2022, 1:53 PM
So am'I right assuming that I can use bpf_process_events instead of bpf_socket_events, to get remote_address?
a

alessandrogario

11/14/2022, 1:53 PM
No, that PR I linked only implements bpf_process_events_v2, there is no bpf_socket_events_v2 yet
s

slevchenko

11/14/2022, 1:53 PM
For my purposes I need either SHA256 or remote_address in cases where it's possible
a

alessandrogario

11/14/2022, 1:54 PM
But you'll be able to do the switch to it in the future when sockets events are added to the new implementation
If you happen to try out that PR (packages can be taken from the CI workflow if you are logged in), let me know how it works on your systems
s

slevchenko

11/14/2022, 1:57 PM
Thanks, I have no CI account, so I'll just wait on this
a

alessandrogario

11/14/2022, 2:00 PM
The GitHub account is enough, I thikn we also have uploaded them in the #ebpf channel
s

slevchenko

11/14/2022, 2:00 PM
I'm mostly interested in capabilities that enable behavioral analysis. So anything related to procfs, DNS requests monitoring are huge selling points to me 🙂
but it looks that I'm kinda alone in this field
a

alessandrogario

11/14/2022, 2:01 PM
I think it's mostly a matter of funding
s

slevchenko

11/14/2022, 2:03 PM
Last quick question. Do you know if there's any way to route osquery logs to unix socket without writing your own logger plugin ?
a

alessandrogario

11/14/2022, 2:10 PM
not really sure, you could ask in #linux
s

slevchenko

11/14/2022, 2:11 PM
Thanks
s

seph

11/15/2022, 3:41 PM
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.
a

alessandrogario

11/15/2022, 3:41 PM
Would there be any issue from the TSC regarding in-core DNS monitoring functionality?
s

seph

11/15/2022, 3:42 PM
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
s

slevchenko

11/15/2022, 3:43 PM
I already wrote a plugin and it works, so I'm just checking if it was necessary
s

seph

11/15/2022, 3:43 PM
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.
s

slevchenko

11/15/2022, 3:45 PM
that was relevant for pcap based functionality as I understood
Now as I understood bpf looks much more promising
To me this looks like invaluable tool to enable DGA generated domains detection, '***.onion' domains detection and overall known malware c2 points detection.
but not sure how broad is a target audience for such feature
a

alessandrogario

11/15/2022, 4:53 PM
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
or rather: packet capture is not bad per se, but some of the libraries we would hve to use to correctly parse the data are