Re: [qubes-users] DNS propagation in Qubes

2019-10-27 Thread David Hobach

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

2019-10-26 Thread gasull
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

2018-03-21 Thread Alex Dubois


Sent from my mobile phone.

> On 13 Mar 2018, at 18:49, David Hobach  wrote:
> 
> 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

2018-03-13 Thread David Hobach

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.


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

2018-03-13 Thread Alex Dubois


Sent from my mobile phone.

> 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

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

2018-03-12 Thread David Hobach

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

2018-03-12 Thread Alex Dubois


Sent from my mobile phone.

> On 11 Mar 2018, at 10:21, Chris Laprise  wrote:
> 
>> 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

2018-03-11 Thread Chris Laprise

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

2018-03-11 Thread David Hobach

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

2018-03-11 Thread David Hobach

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

2018-03-11 Thread Chris Laprise

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.


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

2018-03-10 Thread Alex Dubois
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...

-- 
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

2018-03-10 Thread Micah Lee
‐‐‐ 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.

-- 
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

2018-03-08 Thread Chris Laprise

[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

2018-03-08 Thread Chris Laprise

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

2018-03-08 Thread Yuraeitha
@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

2018-03-08 Thread David Hobach

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

2018-03-07 Thread Unman
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

2018-03-07 Thread Micah Lee
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

2018-03-07 Thread Unman
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

2018-03-07 Thread Micah Lee
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.