vikarti.anatra/safing-web
1
0
Fork 0
mirror of https://github.com/safing/web synced 2025-09-02 11:09:03 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Fix typos

Browse source
This commit is contained in:
davegson 2021-03-19 18:45:08 +01:00
parent 694ae332d0
commit 07e4fffaf9
1 changed files with 15 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
_posts/2021-03-23-attributing-dns-requests-on-windows.md
View file

@ -6,11 +6,11 @@ custom_thumbnail_name:
category: "Dev Log" category: "Dev Log"
--- ---
For an application firewall it is very interesting to know which processes query which domains. For an application firewall it is crucial to know which processes query which domains.
This sounds like an easy thing to achieve, but in practice in turned out to be a rather complicated problem. This sounds like an easy thing to achieve, but in practice it turned out to be a rather complicated problem.
When we first looked into how to find this vital piece of information on Windows 10, we found that for some reason, all dns requests are sent from the "DNS-Client" Windows service. When we first looked into how to find this vital piece of information on Windows 10, we found that for some reason, all DNS requests are sent from the "DNS-Client" Windows service.
There were no dns requests _to_ that service on the wire, just from it. There were no DNS requests _to_ that service on the wire, just _from_ it.
Upon further investigation we found that Windows applications use the `dnsapi.dll` for taking care of DNS requests. Upon further investigation we found that Windows applications use the `dnsapi.dll` for taking care of DNS requests.
These requests are not sent using common DNS packets on the wire, but use a RPC call via an internal IPC mechanism. These requests are not sent using common DNS packets on the wire, but use a RPC call via an internal IPC mechanism.
@ -21,17 +21,17 @@ This means that we could not attribute DNS requests to processes out of the box.
While researching this issue we found that disabling the DNS-Client seemed to be a rather much requested action and quite common for Windows users. While researching this issue we found that disabling the DNS-Client seemed to be a rather much requested action and quite common for Windows users.
Most often, Windows users asked for this in order to work around bugs or to improve some aspect of their network performance. Most often, Windows users asked for this in order to work around bugs or to improve some aspect of their network performance.
So we decided to take the easy route and just disable the DNS-Client upon installation, because it's only a caching stub resolver with no other functionality, right? Right?
### The Bummer ### The Bummer
So we decided to take the easy route and just disable the DNS-Client upon installation, because it is only a caching stub resolver with no other functionality, right? Right?
No. No.
Apparently, the DNS-Client is much more than "just" and caching stub resolver. Apparently, the DNS-Client is much more than "just" a caching stub resolver.
Maybe it should have been a stronger hint to us that Microsoft removed the ability to stop it directly - we had to change a value in the registry and reboot in order to get rid of it. Maybe it should have been a stronger hint to us that Microsoft removed the ability to stop it directly - we had to change a value in the registry and reboot the system in order to get rid of it.
The first reports we got, that made us aware that there is much more to this service, were about VPN clients not working correctly. The first reports we received that made us aware that there is much more to this service, were those of VPN clients not working correctly.
Some of these clients wanted to change the configured DNS server in Windows (which is a good thing - it prevent DNS leaking), but as it turned out, the responsible Windows service for handling these changes is ... the DNS-Client! Some of these clients wanted to change the configured DNS server in Windows (which is a good thing - it prevents DNS leaking), but as it turned out, the responsible Windows service for handling these changes is ... the DNS-Client!
With every report of another broken application that we could attribute to the disabled DNS-Client service, we started to realize that we needed a better solution. With every report of another broken application that we could attribute to the disabled DNS-Client service, we started to realize that we needed a better solution.
All research regarding to finding another way to see the DNS requests without disabling the DNS-Client turned up no viable options - we dismissed the crazy ones: All research regarding to finding another way to see the DNS requests without disabling the DNS-Client turned up no viable options - we dismissed the crazy ones:
@ -43,8 +43,8 @@ All research regarding to finding another way to see the DNS requests without di
With no options available to directly get the needed information, we were left with only one option: Working around the problem on our side. With no options available to directly get the needed information, we were left with only one option: Working around the problem on our side.
Until now, we were able to directly attribute a DNS request to a process due to our "quick and dirty" solution. Until now, we were able to directly attribute a DNS request to a process due to our "quick and dirty" solution.
No longer being able to do that, does mean that we loose some information, and that we will have a slightly less tight grip on the system. No longer being able to do that means that we loose some information, and that we will have a slightly less tight grip on the system.
We will need to find a good balance between control and configurability. We will need to find a good balance between control and configurability
The easiest way to keep control is to make previous app-specific settings global only, because then we just don't need to know the origin of a DNS request anymore to apply settings, but we're not ready to give up configurability so easily. The easiest way to keep control is to make previous app-specific settings global only, because then we just don't need to know the origin of a DNS request anymore to apply settings, but we're not ready to give up configurability so easily.
Previously, we made decisions directly when the DNS request arrived at the Portmaster, at which point we had all the necessary information to evaluate a DNS request. Previously, we made decisions directly when the DNS request arrived at the Portmaster, at which point we had all the necessary information to evaluate a DNS request.
@ -55,7 +55,7 @@ Now, when an app uses the DNS-Client for resolving a domain, it receives a valid
### Positive Side Effects ### Positive Side Effects
Not only Windows has an internal DNS server to take care of DNS requets. Linux distributions are starting to active the DBus interface of systemd-resolved, which in turn also hides DNS requests from us. The workaround presented in this post also successfully works around this. Not only Windows has an internal DNS server to take care of DNS requests. Linux distributions are starting to active the DBus interface of systemd-resolved, which in turn also hides DNS requests from us. The workaround presented in this post also successfully works around this.
Similar system are known to exist and are expected in other operating systems as well, so this change will better brace us for the next systems the Portmaster will be expanded to. Similar system are known to exist and are expected in other operating systems as well, so this change will better brace us for the next systems the Portmaster will be expanded to.
@ -69,16 +69,16 @@ For example, if two processes use two different domains but both of them point t
This also happened before, when a single process sent its DNS requests directly to the Portmaster, but the impact of wrongly attributing a domain in this case was not so high. This also happened before, when a single process sent its DNS requests directly to the Portmaster, but the impact of wrongly attributing a domain in this case was not so high.
As a remediation to this, we will start looking at HTTP headers and TLS handshakes in the future. With information gathered directly from the connection, the attribution will be more accuracte. As a remediation to this, we will start looking at HTTP headers and TLS handshakes in the future. With information gathered directly from the connection, the attribution will be more accurate.
But this will not solve all our problems: But this will not solve all our problems:
- Applications can fake exposed domain information with a method called "Domain Fronting". - Applications can fake exposed domain information with a method called "Domain Fronting".
- TLS 1.3 introduces Encrypted Client Hello messages, which will (partly) hide this information again. - TLS 1.3 introduces Encrypted Client Hello messages, which will (partially) hide this information again.
### Changes to the Portmaster ### Changes to the Portmaster
Here is a full list of changes that this workaround brings: Here is a full list of changes that this workaround brings:
- Domains may be wrongly attributed to connections a bit more often than before. - Domains may be wrongly attributed to connections a bit more often than before.
- The Portmaster will active the DNS-Client Windows Service, which it previously disabled during installation. - The Portmaster will activate the DNS-Client Windows Service, which it previously disabled during installation.
- The DNS-Client in Windows and Linux' systemd-resolved are now categorized as a special "System DNS Client" app in the Portmaster. - The DNS-Client in Windows and Linux' systemd-resolved are now categorized as a special "System DNS Client" app in the Portmaster.
- If you want to disable bypass prevention for an app, you might need to also disable bypass prevention in the "System DNS Client" App in the Portmaster. - If you want to disable bypass prevention for an app, you might need to also disable bypass prevention in the "System DNS Client" App in the Portmaster.
- The Portmaster still works as before with a disabled DNS-Client. Whoever prefers it the way it was, can just disable the DNS-Client manually. - The Portmaster still works as before with a disabled DNS-Client. Whoever prefers it the way it was, can just disable the DNS-Client manually.