Re: [qubes-users] DNS propagation in Qubes
On 10/27/19 6:33 AM, gas...@gmail.com wrote: Is there a clear guide of how to set up a DNS VM in Qubes OS? I tried setting up dnsmasq in the VPN VM behind sys-firewall, both with NetworkManager and as a standalone service. It didn't work. I also tried on another VM behind the VPN VM. All I got working is making DNS requests to the specific VM. E.g. $ dig example.com @10.137.0.23 But I wasn't able to hijack the DNS requests with iptables for general requests without "@". tcpdump seems to indicate that the DNS queries don't even get routed through the VPN VM, which doesn't make sense to me, so I might be missing something. Any clear step-by-step guide anywhere? I randomly found https://blog.tufarolo.eu/how-to-configure-pihole-in-qubesos-proxyvm/ It looks reasonable, but I didn't test it. Use it at your own risk. Depending on your chain of VMs the Qubes firewall may or may not work for DNS - just test it if it matters to you. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4f7f6490-7d5c-3a08-ab56-1bf8060edc87%40hackingthe.net. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] DNS propagation in Qubes
Is there a clear guide of how to set up a DNS VM in Qubes OS? I tried setting up dnsmasq in the VPN VM behind sys-firewall, both with NetworkManager and as a standalone service. It didn't work. I also tried on another VM behind the VPN VM. All I got working is making DNS requests to the specific VM. E.g. $ dig example.com @10.137.0.23 But I wasn't able to hijack the DNS requests with iptables for general requests without "@". tcpdump seems to indicate that the DNS queries don't even get routed through the VPN VM, which doesn't make sense to me, so I might be missing something. Any clear step-by-step guide anywhere? Thanks. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/984347f8-29f0-4436-860a-7dd7fba4237c%40googlegroups.com.
Re: [qubes-users] DNS propagation in Qubes
Sent from my mobile phone. > On 13 Mar 2018, at 18:49, David Hobachwrote: > > On 03/13/2018 07:14 AM, Alex Dubois wrote: >>> On 12 Mar 2018, at 18:40, David Hobach wrote: >>> On 03/11/2018 03:15 PM, David Hobach wrote: An alternative might be to setup the local DNS service in a VM closer to the Internet, i.e. not in the proxy VM which also implements the qubes firewall. Something like Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with qubes-fw <-- client VM I didn't test that though. >>> >>> I just tested that as well now and it works as expected without any of the >>> aforementioned caveats. >>> >>> So I'd recommend the one above over the previously discussed >>> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM >>> (at least I was talking about that architecture - maybe the others were >>> talking about something different...). >>> The same holds true for VPN users. >> This type of architecture is bad practice as the attack surface of DNS is >> bigger than Qubes firewall, and an attack on this daemon compromise all >> traffic, not just DNS. >> A better arch is >> Internet >> - netVM >> - - firewallVM >> - - - Service (ie DNS or VPN) >> - - - clientVM1 >> - - - clientVM2 > > I believe your essential point was not to use proxy VMs for services at all. > > My main point was not to mix a Qubes Firewall VM with local services. I think > you basically agree with that. Yes agree > > I however also disagree with your point wrt proxy VM usage as there's no > attack vector for E2E encrypted traffic on proxy VMs except for DoS which > you'll notice. Let’s agree to disagree;). This is possibly true client to VPN, but the attack surface VPN to internetVPN is not small, there are a substantial number of line of code for the support of various protocols, with negotiation phases, parsing of data stream into such control flow. (I.e. some of the long list of OpenSSL vuln lead to remote code exec I suspect). So my point is you can use proxy if all the clients are going to use the VPN. And this apply also only if all the traffic would flow through the service (VPN use case OK, dns or http proxy not OK). > If you're using non-E2E encrypted traffic (except for maybe DNS) you have a > different problem altogether and even then I'd trust my proxy VM a lot more > than any other hop (your Wifi provider? the 4+ backbone providers you pass?) > on the route to the destination. I may have misunderstood you, but this is outside the subject of the discussion or please clarify. > > Moreover it is rather inconvenient to configure each and every client VM to > use that service VM which can also lead to unexpected misconfigurations & > leakages. I agree that it is less trivial to setup but you lower your attack surface significantly. So I agree that it depends on the circumstances, but I think my statement is preferable as a general rule, and I think Qubes should move toward supporting such setup, making it easier to configure. Best Regards Alex > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/14B0F388-B653-4981-A8B6-D0901E3B5B18%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] DNS propagation in Qubes
On 03/13/2018 07:14 AM, Alex Dubois wrote: On 12 Mar 2018, at 18:40, David Hobachwrote: On 03/11/2018 03:15 PM, David Hobach wrote: An alternative might be to setup the local DNS service in a VM closer to the Internet, i.e. not in the proxy VM which also implements the qubes firewall. Something like Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with qubes-fw <-- client VM I didn't test that though. I just tested that as well now and it works as expected without any of the aforementioned caveats. So I'd recommend the one above over the previously discussed Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM (at least I was talking about that architecture - maybe the others were talking about something different...). The same holds true for VPN users. This type of architecture is bad practice as the attack surface of DNS is bigger than Qubes firewall, and an attack on this daemon compromise all traffic, not just DNS. A better arch is Internet - netVM - - firewallVM - - - Service (ie DNS or VPN) - - - clientVM1 - - - clientVM2 I believe your essential point was not to use proxy VMs for services at all. My main point was not to mix a Qubes Firewall VM with local services. I think you basically agree with that. I however also disagree with your point wrt proxy VM usage as there's no attack vector for E2E encrypted traffic on proxy VMs except for DoS which you'll notice. If you're using non-E2E encrypted traffic (except for maybe DNS) you have a different problem altogether and even then I'd trust my proxy VM a lot more than any other hop (your Wifi provider? the 4+ backbone providers you pass?) on the route to the destination. Moreover it is rather inconvenient to configure each and every client VM to use that service VM which can also lead to unexpected misconfigurations & leakages. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e117d09a-974c-904d-2532-b890b2c77008%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] DNS propagation in Qubes
Sent from my mobile phone. > On 12 Mar 2018, at 18:40, David Hobachwrote: > >> On 03/11/2018 03:15 PM, David Hobach wrote: >> An alternative might be to setup the local DNS service in a VM closer to the >> Internet, i.e. not in the proxy VM which also implements the qubes firewall. >> Something like >> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with >> qubes-fw <-- client VM >> I didn't test that though. > > I just tested that as well now and it works as expected without any of the > aforementioned caveats. > > So I'd recommend the one above over the previously discussed > Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM > (at least I was talking about that architecture - maybe the others were > talking about something different...). > The same holds true for VPN users. This type of architecture is bad practice as the attack surface of DNS is bigger than Qubes firewall, and an attack on this daemon compromise all traffic, not just DNS. A better arch is Internet - netVM - - firewallVM - - - Service (ie DNS or VPN) - - - clientVM1 - - - clientVM2 And firewallVM intercept the traffic for the VM that needs it. Note that a service can also be a client for another service. Note2 that does not mean that the arch should be flat, if you are worried that a mis conf of firewallVM could put you at risk you could do Internet - NetVM - - FirewallVM - - - FirewallVPN - - - - clientVPNVM - - - - vpmServiceVM - - - firewallDNS - - - - clientDNSVM - - - - dnsServiceVM - - - firewallWebServer - - - - ReverseProxyAuthVMservice - - - - - webServerVMservice - - - - - - webDMserviceVM - - - - ClientWebVM > > I also documented this at https://github.com/QubesOS/qubes-issues/issues/3051 > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/C3D0CBC3-8C5A-4BB5-B866-866E9B3144D9%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] DNS propagation in Qubes
On 03/11/2018 03:15 PM, David Hobach wrote: An alternative might be to setup the local DNS service in a VM closer to the Internet, i.e. not in the proxy VM which also implements the qubes firewall. Something like Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with qubes-fw <-- client VM I didn't test that though. I just tested that as well now and it works as expected without any of the aforementioned caveats. So I'd recommend the one above over the previously discussed Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM (at least I was talking about that architecture - maybe the others were talking about something different...). The same holds true for VPN users. I also documented this at https://github.com/QubesOS/qubes-issues/issues/3051 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b1482304-c9c8-11d6-c988-4adcc737380b%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] DNS propagation in Qubes
Sent from my mobile phone. > On 11 Mar 2018, at 10:21, Chris Laprisewrote: > >> On 03/10/2018 04:43 PM, Alex Dubois wrote: >>> On Saturday, 10 March 2018 13:16:37 UTC, Micah Lee wrote: >>> ‐‐‐ Original Message ‐‐‐ >>> On March 8, 2018 11:26 AM, Chris Laprise wrote: >>> \> \[1\] https://dnsprivacy.org/wiki/ \[2\] https://www.qubes-os.org/doc/networking/ Micah, If you have any specific instructions on how to setup the forwarder you're using, I'd be happy to try it myself and post a solution for use with qubes-firewall. I found the dnsprivacy wiki to be a bit scattered and not very specific. Their video "tutorial" is really a lecture on the concept. >>> >>> Thanks, yes I'd love to share instructions. I haven't gotten it working yet >>> -- I'm traveling right now and haven't spent a lot of time on it, and might >>> not for the next week or two. But once I figure it out I'd like to write a >>> blog post or something with instructions. But maybe I should sent it to >>> this list first for people to test and give feedback. >> For your info, I have a wiki on how to use dns-crypt here: >> https://github.com/adubois/adubois.github.io/blob/master/_posts/2013-11-19-setup-dnscrypt-unbound.md >> It is supposed to be exposed via blog.bowabos.com but github changed >> something and the static site does not get automatically generated at the >> moment... > > Nice. I gave this a try on debian-9, using apt to install dnscrypt-proxy and > unbound. > > One problem is that the howto assumes particular Qubes 10.137.2.x and > 10.138.2.x nets for unbound. Yes I need to rewrite it for Qubes 4. The other blog post on Atlassian stack also needs a rewrite and I have now a better network topology (more secure) for it. Time is my problem > > Another problem is that on Qubes 4.0 the vif interfaces plus eth0 all share > the same IP address. This isn't explained in the Qubes networking or firewall > docs, so it may be a bug... > > To keep unbound.service from failing I changed unbound.conf to this: > >> interface: >> access-control: 10.137.0.0/24 allow >> harden-large-queries: yes >> private-address: 10.0.0.0/8 >> private-address: 192.168.0.0/16 >> val-permissive-mode: yes >> do-not-query-localhost: no > > ...and for now omitted the '-d' destination part in iptables. > > Then if I issue: > >> sudo iptables -t nat -F PR-QBS >> sudo iptables -t nat -A PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to >> $eth0_address >> sudo iptables -t nat -A PR-QBS -i vif+ -p tcp --dport 53 -j DNAT --to >> $eth0_address > > it appears to work from a downstream appVM. But I haven't checked yet to see > if its really using the dnscrypt proxy; even if it is, the config may need to > be adjusted for better security. > > -- > > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8ECF3140-FD4B-400C-AB7D-A459F74327AC%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] DNS propagation in Qubes
On 03/11/2018 10:03 AM, David Hobach wrote: On 03/11/2018 11:21 AM, Chris Laprise wrote: ...and for now omitted the '-d' destination part in iptables. Then if I issue: sudo iptables -t nat -F PR-QBS sudo iptables -t nat -A PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to $eth0_address sudo iptables -t nat -A PR-QBS -i vif+ -p tcp --dport 53 -j DNAT --to $eth0_address it appears to work from a downstream appVM. But I haven't checked yet to see if its really using the dnscrypt proxy; even if it is, the config may need to be adjusted for better security. I just tested that one (my implementation was also doing pretty much exactly that + a local INPUT chain firewall so it was a 5 min test removing the INPUT firewall): Since you'll need something like -I INPUT -p udp -m udp --dport 53 -j ACCEPT -I INPUT -p tcp -m tcp --dport 53 -j ACCEPT I used this, which is Alex's example without '-d': iptables -I INPUT 3 -j ACCEPT -p udp --sport 1024:65535 --dport 53 -m conntrack --ctstate NEW it makes DNS accessible for all downstream VMs regardless of the qubes-firewall settings, i.e. apprently the nft FORWARD rules are not applied for DNAT to localhost. That's probably why I had opened that github issue & implemented a local firewall back then... You can verify my findings by using the dom0 qvm-firewall command line to revoke DNS access for a downstream VM & then use e.g. dig in that VM. The qubes-vm-settings GUI won't work as in 4.0 DNS & ICMP is always allowed. So yes, if one is aware of that issue, one can certainly use it the way you described. If you rely on the qubes-firewall to work as expected, you shouldn't use it. Thanks for the specific caveat. Qubes 3.2 firewall had a dns incompatibility when you configured a tunnel such as openvpn. I was able to fix that problem (pretty seamlessly) with sed :) . -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a802b5cd-0b42-c548-716b-3eaf3519f17d%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] DNS propagation in Qubes
On 03/11/2018 03:03 PM, David Hobach wrote: So yes, if one is aware of that issue, one can certainly use it the way you described. If you rely on the qubes-firewall to work as expected, you shouldn't use it. P.S.: An alternative might be to setup the local DNS service in a VM closer to the Internet, i.e. not in the proxy VM which also implements the qubes firewall. Something like Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with qubes-fw <-- client VM I didn't test that though. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ec054435-0c3c-9517-f02f-f9c2c50c19a8%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] DNS propagation in Qubes
On 03/11/2018 11:21 AM, Chris Laprise wrote: ...and for now omitted the '-d' destination part in iptables. Then if I issue: sudo iptables -t nat -F PR-QBS sudo iptables -t nat -A PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to $eth0_address sudo iptables -t nat -A PR-QBS -i vif+ -p tcp --dport 53 -j DNAT --to $eth0_address it appears to work from a downstream appVM. But I haven't checked yet to see if its really using the dnscrypt proxy; even if it is, the config may need to be adjusted for better security. I just tested that one (my implementation was also doing pretty much exactly that + a local INPUT chain firewall so it was a 5 min test removing the INPUT firewall): Since you'll need something like -I INPUT -p udp -m udp --dport 53 -j ACCEPT -I INPUT -p tcp -m tcp --dport 53 -j ACCEPT it makes DNS accessible for all downstream VMs regardless of the qubes-firewall settings, i.e. apprently the nft FORWARD rules are not applied for DNAT to localhost. That's probably why I had opened that github issue & implemented a local firewall back then... You can verify my findings by using the dom0 qvm-firewall command line to revoke DNS access for a downstream VM & then use e.g. dig in that VM. The qubes-vm-settings GUI won't work as in 4.0 DNS & ICMP is always allowed. So yes, if one is aware of that issue, one can certainly use it the way you described. If you rely on the qubes-firewall to work as expected, you shouldn't use it. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ba33e227-187d-4945-6b51-d1ef0093d21a%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] DNS propagation in Qubes
On 03/10/2018 04:43 PM, Alex Dubois wrote: On Saturday, 10 March 2018 13:16:37 UTC, Micah Lee wrote: ‐‐‐ Original Message ‐‐‐ On March 8, 2018 11:26 AM, Chris Laprisewrote: \> \[1\] https://dnsprivacy.org/wiki/ \[2\] https://www.qubes-os.org/doc/networking/ Micah, If you have any specific instructions on how to setup the forwarder you're using, I'd be happy to try it myself and post a solution for use with qubes-firewall. I found the dnsprivacy wiki to be a bit scattered and not very specific. Their video "tutorial" is really a lecture on the concept. Thanks, yes I'd love to share instructions. I haven't gotten it working yet -- I'm traveling right now and haven't spent a lot of time on it, and might not for the next week or two. But once I figure it out I'd like to write a blog post or something with instructions. But maybe I should sent it to this list first for people to test and give feedback. For your info, I have a wiki on how to use dns-crypt here: https://github.com/adubois/adubois.github.io/blob/master/_posts/2013-11-19-setup-dnscrypt-unbound.md It is supposed to be exposed via blog.bowabos.com but github changed something and the static site does not get automatically generated at the moment... Nice. I gave this a try on debian-9, using apt to install dnscrypt-proxy and unbound. One problem is that the howto assumes particular Qubes 10.137.2.x and 10.138.2.x nets for unbound. Another problem is that on Qubes 4.0 the vif interfaces plus eth0 all share the same IP address. This isn't explained in the Qubes networking or firewall docs, so it may be a bug... To keep unbound.service from failing I changed unbound.conf to this: interface: access-control: 10.137.0.0/24 allow harden-large-queries: yes private-address: 10.0.0.0/8 private-address: 192.168.0.0/16 val-permissive-mode: yes do-not-query-localhost: no ...and for now omitted the '-d' destination part in iptables. Then if I issue: sudo iptables -t nat -F PR-QBS sudo iptables -t nat -A PR-QBS -i vif+ -p udp --dport 53 -j DNAT --to $eth0_address sudo iptables -t nat -A PR-QBS -i vif+ -p tcp --dport 53 -j DNAT --to $eth0_address it appears to work from a downstream appVM. But I haven't checked yet to see if its really using the dnscrypt proxy; even if it is, the config may need to be adjusted for better security. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6be04a34-d79d-df7f-cd64-68d098613df6%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] DNS propagation in Qubes
On Saturday, 10 March 2018 13:16:37 UTC, Micah Lee wrote: > ‐‐‐ Original Message ‐‐‐ > > On March 8, 2018 11:26 AM, Chris Laprisewrote: > > > > > > > >>>\> \[1\] https://dnsprivacy.org/wiki/ > > > > > > > > \[2\] https://www.qubes-os.org/doc/networking/ > > > > Micah, > > > > If you have any specific instructions on how to setup the forwarder > > > > you're using, I'd be happy to try it myself and post a solution for use > > > > with qubes-firewall. > > > > I found the dnsprivacy wiki to be a bit scattered and not very specific. > > > > Their video "tutorial" is really a lecture on the concept. > > Thanks, yes I'd love to share instructions. I haven't gotten it working yet > -- I'm traveling right now and haven't spent a lot of time on it, and might > not for the next week or two. But once I figure it out I'd like to write a > blog post or something with instructions. But maybe I should sent it to this > list first for people to test and give feedback. For your info, I have a wiki on how to use dns-crypt here: https://github.com/adubois/adubois.github.io/blob/master/_posts/2013-11-19-setup-dnscrypt-unbound.md It is supposed to be exposed via blog.bowabos.com but github changed something and the static site does not get automatically generated at the moment... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/11825052-26fe-48a8-bd08-7da3f15b7787%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] DNS propagation in Qubes
‐‐‐ Original Message ‐‐‐ On March 8, 2018 11:26 AM, Chris Laprisewrote: > > > >>>\> \[1\] https://dnsprivacy.org/wiki/ > > > > > > \[2\] https://www.qubes-os.org/doc/networking/ > > Micah, > > If you have any specific instructions on how to setup the forwarder > > you're using, I'd be happy to try it myself and post a solution for use > > with qubes-firewall. > > I found the dnsprivacy wiki to be a bit scattered and not very specific. > > Their video "tutorial" is really a lecture on the concept. Thanks, yes I'd love to share instructions. I haven't gotten it working yet -- I'm traveling right now and haven't spent a lot of time on it, and might not for the next week or two. But once I figure it out I'd like to write a blog post or something with instructions. But maybe I should sent it to this list first for people to test and give feedback. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/pPIWHaxl0Lwz4sF1qRHn34jz0i4_oDljtkWk8CQMPNnOtFFKBsOS7gaUGQqLXC9ZFprlaPHpcPW_4IX_LKKwm9no1c-DO7byugnObo8aXzY%3D%40micahflee.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] DNS propagation in Qubes
[1] https://dnsprivacy.org/wiki/ [2] https://www.qubes-os.org/doc/networking/ Micah, If you have any specific instructions on how to setup the forwarder you're using, I'd be happy to try it myself and post a solution for use with qubes-firewall. I found the dnsprivacy wiki to be a bit scattered and not very specific. Their video "tutorial" is really a lecture on the concept. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/cbdcbcac-00c8-9476-3e94-04a4a6b9e9bc%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] DNS propagation in Qubes
On 03/08/2018 01:16 PM, David Hobach wrote: On 03/07/2018 06:40 PM, Unman wrote: On Wed, Mar 07, 2018 at 11:58:21AM -0500, Micah Lee wrote: I'm trying to make all DNS requests in Qubes go over TLS (more information about this [1]). I've got this successfully working in sys-net by running a local DNS server on udp 53 that forwards DNS requests to a remote DNS server over TLS, and then setting my only nameserver in /etc/resolv.conf to 127.0.0.1. I've confirmed that this works great in sys-net -- all of my DNS requests are encrypted to my remote DNS server, and none are plaintext. The problem is when I do this, DNS in other downstream VMs all fail. The Qubes networking docs [2] explain how DNS works in Qubes, but I'm confused about how to make this set up work. Any ideas? Thanks! [1] https://dnsprivacy.org/wiki/ [2] https://www.qubes-os.org/doc/networking/ In sys-net you have PR-QBS chain in nat table that redirects DNS requests to the network DNS server. You'll need to remove that chain and replace it with one directing DNS traffic to the local server. You'll also need to open the udp port to inbound traffic. If you do that, you'll lose any qubes firewall-based control on DNS traffic though. I.e. all of your downstream VMs will have DNS access. Essentially you'll have to implement your own local version of the qubes firewall to achieve qubes-firewall support. I happened to have done that some time ago, but the code quality is not good enough to share it (sorry). nft usage in 4.0 further complicates it from my point of view. You could try to move the forward chain rules to the input chain on every firewall change... Maybe qubes will support it one day; here's the feature request: https://github.com/QubesOS/qubes-issues/issues/3051 I'm not sure why it got tagged as doc though - maybe I didn't see the obvious solution. If this is about changing the iptables rules in a proxyVM, then you're allowed to do so with qubes-firewall-user-script and the new qubes-firewall.d in /rw/config. Just be mindful of what the default rules are and Insert/Append as needed. For example, if you don't want DNS requests to be routed elsewhere you can flush the PR-QBS chain in the nat table and maybe add another dnat rule there redirecting to localhost (this would catch all DNS requests, not just the ones sent to the Qubes internal DNS addresses). Then you can add an INPUT rule for port 53. Maybe I'm missing something but this doesn't look hard. As another possible avenue if the above fails, you could look for a guide to setting up 'stubby' on a local router; this has the best chance of working as proxyVMs are much like routers. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/599cfc5e-d7e8-b2c0-88f0-a1ace3064cff%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] DNS propagation in Qubes
@David On Thursday, March 8, 2018 at 7:18:04 PM UTC+1, David Hobach wrote: > On 03/07/2018 06:40 PM, Unman wrote: > > On Wed, Mar 07, 2018 at 11:58:21AM -0500, Micah Lee wrote: > >> I'm trying to make all DNS requests in Qubes go over TLS (more information > >> about this [1]). > >> > >> I've got this successfully working in sys-net by running a local DNS > >> server on udp 53 that forwards DNS requests to a remote DNS server over > >> TLS, and then setting my only nameserver in /etc/resolv.conf to 127.0.0.1. > >> I've confirmed that this works great in sys-net -- all of my DNS requests > >> are encrypted to my remote DNS server, and none are plaintext. > >> > >> The problem is when I do this, DNS in other downstream VMs all fail. The > >> Qubes networking docs [2] explain how DNS works in Qubes, but I'm confused > >> about how to make this set up work. Any ideas? Thanks! > >> > >> [1] https://dnsprivacy.org/wiki/ > >> [2] https://www.qubes-os.org/doc/networking/ > >> > > > > In sys-net you have PR-QBS chain in nat table that redirects DNS > > requests to the network DNS server. > > > > You'll need to remove that chain and replace it with one directing DNS > > traffic to the local server. > > You'll also need to open the udp port to inbound traffic. > > If you do that, you'll lose any qubes firewall-based control on DNS > traffic though. I.e. all of your downstream VMs will have DNS access. > > Essentially you'll have to implement your own local version of the qubes > firewall to achieve qubes-firewall support. I happened to have done that > some time ago, but the code quality is not good enough to share it > (sorry). nft usage in 4.0 further complicates it from my point of view. > You could try to move the forward chain rules to the input chain on > every firewall change... > > Maybe qubes will support it one day; here's the feature request: > https://github.com/QubesOS/qubes-issues/issues/3051 > I'm not sure why it got tagged as doc though - maybe I didn't see the > obvious solution. We're currently trying to start a Qubes Community doc guide collection at the moment, which is thought to be entirely run by volunteers on day-to-day in order to help save the Qubes staff time. Nothing official yet though, but here one of the ideas being worked on is so you can open up your script to allow others to help you finish it and review it. Basically, if this comes to fruition, then it allows you to publish unfinished scripts, either to work with others and finish it together, or let others takeover if you don't want to continue it. Kinda something like that, of course credits should be put like always. If this comes to fruition, maybe you can start up a collaboration to have people with the right background review it and quality check it? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c20a76d2-dcb5-4e5b-8fbe-7f83510e6e0b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] DNS propagation in Qubes
On 03/07/2018 06:40 PM, Unman wrote: On Wed, Mar 07, 2018 at 11:58:21AM -0500, Micah Lee wrote: I'm trying to make all DNS requests in Qubes go over TLS (more information about this [1]). I've got this successfully working in sys-net by running a local DNS server on udp 53 that forwards DNS requests to a remote DNS server over TLS, and then setting my only nameserver in /etc/resolv.conf to 127.0.0.1. I've confirmed that this works great in sys-net -- all of my DNS requests are encrypted to my remote DNS server, and none are plaintext. The problem is when I do this, DNS in other downstream VMs all fail. The Qubes networking docs [2] explain how DNS works in Qubes, but I'm confused about how to make this set up work. Any ideas? Thanks! [1] https://dnsprivacy.org/wiki/ [2] https://www.qubes-os.org/doc/networking/ In sys-net you have PR-QBS chain in nat table that redirects DNS requests to the network DNS server. You'll need to remove that chain and replace it with one directing DNS traffic to the local server. You'll also need to open the udp port to inbound traffic. If you do that, you'll lose any qubes firewall-based control on DNS traffic though. I.e. all of your downstream VMs will have DNS access. Essentially you'll have to implement your own local version of the qubes firewall to achieve qubes-firewall support. I happened to have done that some time ago, but the code quality is not good enough to share it (sorry). nft usage in 4.0 further complicates it from my point of view. You could try to move the forward chain rules to the input chain on every firewall change... Maybe qubes will support it one day; here's the feature request: https://github.com/QubesOS/qubes-issues/issues/3051 I'm not sure why it got tagged as doc though - maybe I didn't see the obvious solution. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e60f357b-99ed-fa8d-8909-978200662b95%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qubes-users] DNS propagation in Qubes
On Wed, Mar 07, 2018 at 11:58:21AM -0500, Micah Lee wrote: > I'm trying to make all DNS requests in Qubes go over TLS (more information > about this [1]). > > I've got this successfully working in sys-net by running a local DNS server > on udp 53 that forwards DNS requests to a remote DNS server over TLS, and > then setting my only nameserver in /etc/resolv.conf to 127.0.0.1. I've > confirmed that this works great in sys-net -- all of my DNS requests are > encrypted to my remote DNS server, and none are plaintext. > > The problem is when I do this, DNS in other downstream VMs all fail. The > Qubes networking docs [2] explain how DNS works in Qubes, but I'm confused > about how to make this set up work. Any ideas? Thanks! > > [1] https://dnsprivacy.org/wiki/ > [2] https://www.qubes-os.org/doc/networking/ > In sys-net you have PR-QBS chain in nat table that redirects DNS requests to the network DNS server. You'll need to remove that chain and replace it with one directing DNS traffic to the local server. You'll also need to open the udp port to inbound traffic. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20180307174022.u5dknqjh3oimwfq3%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] DNS propagation in Qubes
Qubes 4.0. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/X1juIg1dY5HqEdgRRiliD8belJfZZE8Zt-UAwN3VNsQETPt6oVLAVSRCgd8H0Zq_LvFJz6fWTeYPMKPGjolws8qqCHF8RsbhrtuNz1FpOVc%3D%40micahflee.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] DNS propagation in Qubes
On Wed, Mar 07, 2018 at 11:58:21AM -0500, Micah Lee wrote: > I'm trying to make all DNS requests in Qubes go over TLS (more information > about this [1]). > > I've got this successfully working in sys-net by running a local DNS server > on udp 53 that forwards DNS requests to a remote DNS server over TLS, and > then setting my only nameserver in /etc/resolv.conf to 127.0.0.1. I've > confirmed that this works great in sys-net -- all of my DNS requests are > encrypted to my remote DNS server, and none are plaintext. > > The problem is when I do this, DNS in other downstream VMs all fail. The > Qubes networking docs [2] explain how DNS works in Qubes, but I'm confused > about how to make this set up work. Any ideas? Thanks! > > [1] https://dnsprivacy.org/wiki/ > [2] https://www.qubes-os.org/doc/networking/ > Which Qubes version are you using Micah? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2018030717.hawe2u54neblst5q%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] DNS propagation in Qubes
I'm trying to make all DNS requests in Qubes go over TLS (more information about this [1]). I've got this successfully working in sys-net by running a local DNS server on udp 53 that forwards DNS requests to a remote DNS server over TLS, and then setting my only nameserver in /etc/resolv.conf to 127.0.0.1. I've confirmed that this works great in sys-net -- all of my DNS requests are encrypted to my remote DNS server, and none are plaintext. The problem is when I do this, DNS in other downstream VMs all fail. The Qubes networking docs [2] explain how DNS works in Qubes, but I'm confused about how to make this set up work. Any ideas? Thanks! [1] https://dnsprivacy.org/wiki/ [2] https://www.qubes-os.org/doc/networking/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9XVz-7viQEqd-6MPx8NvR4Fnk502VgBDJUYogFE056xaFr-k76ApY7WmEbi3oH6yQZQ7MEHbuqYbwCZInJ8LE9lysw_e3w8Dw93FrISL2hU%3D%40micahflee.com. For more options, visit https://groups.google.com/d/optout.