Closed lepasserby closed 5 years ago
Probably it will be more complicated, but I'd like to control access based on the requested DNS names too.
@Forkest do you mean filtering the DNS requests based on the name like for instance if I blocked myapp.com
in Douane, that all request to this name are blocked?
I'd like to have such functionality so that I could allow a program to connect to specific domains or subdomains only, like a white list, or vice versa - allow everything, except some domains, like a black list. In the interface I expect to be able to use a domain name in the places where I am able to use an IP address.
But what is the best way to implement this is to be decided. Probably intercept and inspect all DNS queries of the application to allow or disallow access to IPs behind the domains. Or maybe block the disallowed domains right on the DNS query level. For example, Hands Off! for Mac allows to do both, although I'm not sure if this much control is practically needed. What I'd rather like to see that is not on the screenshot is the ability to allow/deny the entire domain when a subdomain is requested.
Ha, it's clearer know @Forkest thank you
It would be nice if we were given just a tiny bit more flexibility with regards to the rules for applications being allowed / blocked.
Specifically, it would be nice to have the ability to specify which interfaces the applications are allowed to use, which IPs/subnets and ports they are allowed to access (if any), which is pretty much bread-and-butter of firewalls, in my humble opinion.
Possible usecase: In a VPN setting, only allow direct internet access to applications responsible for monitoring, maintaining and (in case of failure) re-establishing the VPN connection, while limiting all other applications to the VPN's tun, localhost, or LAN.
Specifically, in case of Mullvad (pretty decent VPN), that would mean allowing unfettered internet access to mullvad (python2), openvpn, and (in some cases) obfsproxy while limiting all other applications to tun interface, LAN connectivity and localhost.
In case of connection "hiccup" and / or mullvad daemon crash, Douane would prevent traffic from escaping to the internet, but LAN-related stuff (such as network printer) and daemons listening on localhost would still be okay. More importantly, upon restart of mullvad daemon the system will be able to re-establish VPN connection (including obfsproxy-enabled VPN connection) and resume normal operation without additional intervention on user's part.
Another usecase: Prevent TOR browser leaks. Everything but TOR is only allowed localhost (where TOR listens), while TOR remains unfettered. In case TOR browser becomes compromised by malicious javascript or plugin (assuming there is no privilege escalation involved, the malicious script / plugin would not be able to bypass Douane and phone home, since "everything but TOR" is prohibited from direct internet access.