Feb 14, 2019, 3:42 PM by un...@thirdeyesecurity.org:
> On Thu, Feb 14, 2019 at 03:13:00PM +0100, > ashleybrown...@tutanota.com > <mailto:ashleybrown...@tutanota.com>> wrote: > >> >> >> Hopefully one day they revert it back to how it was in 3.2. A very common >> use-case for the firewall is likely to ensure things like DNS requests do >> not happen through the normal means (and instead go over something like Tor >> or a VPN). Unfortunately, the current config does not make it very obvious >> that someone should block DNS ports. Making it very easy for someone to >> shoot themselves in the foot because the interface is not intuitive (it says >> it blocks all traffic other than what is specified and then later modifies >> this saying "just kidding, we let DNS through") >> >> Feb 14, 2019, 2:05 PM by >> ashleybrown...@tutanota.com >> <mailto:ashleybrown...@tutanota.com>>> : >> >> > > The magic is in NAT rules (but I had to research this too.) See > >> >> > > https://www.qubes-os.org/doc/networking >> > > <https://www.qubes-os.org/doc/networking>>> <>> >> > > https://www.qubes-os.org/doc/networking >> > > <https://www.qubes-os.org/doc/networking/>>> >> , and "sudo iptables -t >> > > nat -L" in sys-firewall and sys-net. >> > >> > I previously looked at IP tables and honestly I really do not understand >> > it. Can you please explain a little how it works? >> > >> > Here is what my nat look like in sys-firewall: >> > >> > Chain PR-QBS (1 references) >> > target prot opt source destination >> > DNAT udp -- anywhere 10.139.1.1 udp >> > dpt:domain to:10.139.1.1 >> > DNAT tcp -- anywhere 10.139.1.1 tcp >> > dpt:domain to:10.139.1.1 >> > DNAT udp -- anywhere 10.139.1.2 udp >> > dpt:domain to:10.139.1.2 >> > DNAT tcp -- anywhere 10.139.1.2 tcp >> > dpt:domain to:10.139.1.2 >> > >> > So, when I do ping google.com it needs to do a DNS request. Because my >> > AppVm /etc/resolv.conf is set to 10.139.1.1 it creates a DNS request to >> > send to 10.139.1.1. However, no VM on the network actually has this >> > address. >> > >> > Is that packet modified? I am assuming what happens is the packet is >> > forwarded to whoever the internet provider is (in this case sys-firewall). >> > Sys-firewall then forwards it to sys-net. Sys-net then forwards it to the >> > DNS server. >> > >> > I am assuming the IP-Header of each hop is rewritten. So, for example, >> > sys-net will rewrite the IP header to be the external IP address for the >> > computer and thus it will receive a response to that IP. Assuming this is >> > correct how does the original AppVM get the correct response? I assume >> > multiple AppVMs are all forwarding these UDP dns requests through >> > sys-firewall and then sys-net. And then when sys-net gets a response how >> > does it know to send which response to which specific AppVM? >> > >> > -- >> > Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: >> > >> https://tutanota.com <https://tutanota.com>>> <>> https://tutanota.com >> > >> <https://tutanota.com>>> > >> > >> > >> > Feb 14, 2019, 11:46 AM by > >> qubes-users@googlegroups.com >> > <mailto:qubes-users@googlegroups.com>>> <mailto:>> >> > qubes-users@googlegroups.com <mailto:qubes-users@googlegroups.com>>> >> : >> > >> >> >> ashleybrown...@tutanota.com <mailto:ashleybrown...@tutanota.com>>> >> >> >> <mailto:>> ashleybrown...@tutanota.com >> >> >> <mailto:ashleybrown...@tutanota.com>>> >>> wrote on 2/14/19 6:28 AM: >> >> >> >>> When I look at /etc/resolv.conf in the following VMs it says different >> >>> things: >> >>> >> >>> 1) Normal AppVM: >> >>> >> >>> nameserver 10.139.1.1 >> >>> nameserver 10.139.1.2 >> >>> >> >>> 2) Sys-firewall VM: >> >>> >> >>> nameserver 10.139.1.1 >> >>> nameserver 10.139.1.2 >> >>> >> >>> 3) Sys-net VM: >> >>> >> >>> [actual resolvers] >> >>> >> >>> The chain for DNS packets is obviously AppVM -> Sys-firewall -> sys-net >> >>> >> >>> However, what I don't undersatnd is that 10.139.1.1 does not exist. That >> >>> is not the IP address for any VM on the network. This can be verified >> >>> in Qubes Manager looking at the IP column. In addition, 10.139.1.1 >> >>> refers to different VMs depending on the VM sending the packets. In >> >>> AppVM it routes to sys-firewall. In sys-firewall it routes to sys-net. >> >>> >> >>> So, my question is how does all of this work? Where exactly does any >> >>> request to 10.139.1.1 route to the actual connected VM. Looking at IP >> >>> table rules I do not see where traffic sent to 10.139.1.1 goes to >> >>> [sys-firewall IP here] for example. It appears to be doing it all >> >>> magically, so where is the magic? >> >>> >> >> >> >> The magic is in NAT rules (but I had to research this too.) See >> >> >> >> https://www.qubes-os.org/doc/networking >> >> <https://www.qubes-os.org/doc/networking>>> <>> >> >> https://www.qubes-os.org/doc/networking >> >> <https://www.qubes-os.org/doc/networking/>>> >>> , and "sudo iptables -t >> >> nat -L" in sys-firewall and sys-net. >> >> >> > > Please don't top post. Take a minute to make it easier for other users. > As is clear in another thread, there is a clear warning about DNS on the > GUI firewall - I find it hard to believe that anyone could miss this. > I am new to mailing lists. What does top-post mean? Do you mean don't post the reply at the top of the message and instead at the bottom like this? -- 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/LYjzz2s--3-1%40tutanota.com. For more options, visit https://groups.google.com/d/optout.
