search

microsoft / ebpf-for-windows

eBPF implementation that runs on top of Windows
MIT License
2.93k stars 234 forks source link

DNS Hook Feature... #214

Open vparla opened 3 years ago

vparla commented 3 years ago

With the adoption of DoH technology (DNS over HTTPS) - Endpoint Security solutions that rely on classic DNS [Do53] visibility no longer function. (This includes advanced VPN features like Domain Split Tunneling and advanced DNS security features).

Unlike other OSes Vendors that offer a DNSProxy System API framework to solve this problem, Microsoft does not have such a capability or framework available for encrypted-DNS in the OS Stack.

It means that these network level security frameworks can no longer operate when DoH is enabled, forcing them to block / disable DoH functionality in a brute-force manner.

It would be great if eBPF could support a new hook to provide DNS visibility (like other OS frameworks already offer), even when DoH is enabled in the OS Resolver.
This hook should include the ability to observe, inject or modify/drop DNS request/responses.

dthaler commented 3 years ago

@vparla sounds very interesting and useful, are you aware of such a hook on Linux or any other eBPF platform today?

vparla commented 3 years ago

Well DoH is not really standardized in the OS Resolver on Linux. You can do many Do53 tasks today on Linux via eBPF. one example: https://dnsdist.org/advanced/ebpf.html On another non-Windows/non-Linux platform there is a native OS Framework that provides DNSProxy capability for DoH, obviating the need for eBPF hooking.

dthaler commented 3 years ago

That matches my understanding, so this feature request is really a cross-platform ask (including Windows), not a Windows-only ask per se.

vparla commented 3 years ago

Well - It really is Windows first and foremost because there is not standardized DoH resolver service on Linux - and another platform - not Windows or Linux, has a built in OS framework addressing this today (that Windows lacks).

So the immediate problem is on Windows, and eventually Linux when it is part of the native OS resolver.

Additionally, given Windows is heavily invested in moving DoH ecosystem forward and has many DoH capabilities in the native resolver today, it makes sense to lead with Windows.

dthaler commented 3 years ago

On Linux today the closest thing available would be a kprobe hook for observability of DNS resolution, and then block at a separate hook in TCP/IP, and use a map to pass information between the two.

Microsoft Defender Client has a similar client used for anti-phishing, so there could possibly be some integration with that on Windows?

vparla commented 3 years ago

On Linux today the closest thing available would be a kprobe hook for observability of DNS resolution, and then block at a separate hook in TCP/IP, and use a map to pass information between the two.

Microsoft Defender Client has a similar client used for anti-phishing, so there could possibly be some integration with that on Windows?

Can you elaborate a bit more how you envision this working with a native DoH resolver implementation? How do you know which TLS packets contain the DNS resolution information in them? Also, you can't disrupt the TLS stream and just drop some of the packets.

I think the DoH hook would have to work on the unencrypted side of the resolution process in the Native Resolver itself. Hence the purpose-built hook being needed in the Native Resolver itself to support this.

poornagmsft commented 3 years ago

On Linux today the closest thing available would be a kprobe hook for observability of DNS resolution, and then block at a separate hook in TCP/IP, and use a map to pass information between the two. Microsoft Defender Client has a similar client used for anti-phishing, so there could possibly be some integration with that on Windows?

Can you elaborate a bit more how you envision this working with a native DoH resolver implementation? How do you know which TLS packets contain the DNS resolution information in them? Also, you can't disrupt the TLS stream and just drop some of the packets.

I think the DoH hook would have to work on the unencrypted side of the resolution process in the Native Resolver itself. Hence the purpose-built hook being needed in the Native Resolver itself to support this.

The requests will indeed be encrypted as you note in case of DoH. A hook prior to encryption would have some challenges if the encryption is done in usermode such as in an application context or system service context. Most importantly, there is a privacy side of the conversation here that is great to have at a broader forum such as at the IETF.