On 11/11/2016 01:24 PM, David Hobach wrote:
On 11/10/2016 10:07 PM, Chris Laprise wrote:
> On 11/10/2016 01:28 PM, David Hobach wrote:
>> I'd recommend to avoid any tools employing iptables which were not
>> written explicitly for Qubes as well.
>
> This. Or at least don't use them without careful inspection.
Might be worth to put some warning on the wiki page for less
experienced users...
> I would also advise users *not* to
> rely on firewall settings in Qubes Manager/VM Settings as the options
> are too limited to stop compromised VMs that are supposed to be
confined
> to the VPN tunnel from leaking data to clearnet (e.g. a hostile access
> point or other upstream node) regardless of which address/port you
specify.
Can you please explain that in a more detailed way?
Currently I disagree as I don't see a way to leak anything if the user
employs the Qubes Firewall for the proxy VM to only allow access to
his VPN gateway IPs (preferably not hostnames) and disallows
everything else (incl. DNS); in particular nothing is leaked when the
VPN is down.
This approach might not work for all VPN providers as some e.g. do
load balancing via DNS or other tricks, but for some it does. For the
others, yes, Qubes Firewall might be too limited.
People often use VPNs to safely access the Internet through Wifi access
points and routers and ISPs that are hostile. If the VPN-connected appVM
is compromised it could search for the VPN IP address in order to send
cleartext to the router. All of the known VPN addresses in the world
could very easily be programmed into the malware, as this search space
is tiny compared to the number of IPv4 addresses.
So we have a way of blocking anything at all that might be forwarded to
the upstream network interface. This is much better than filtering by
IP. Users can employ whatever addressing scheme, and we don't have to
instruct them to hard-code IP addresses into scripts, config files and
VM settings... the address preconfigured in a downloaded config file
will work automatically and be completely protected.
Side note: I recently ran into
https://github.com/QubesOS/qubes-issues/issues/1183 - I'm still not
100% sure whether it's absolutely impossible to get some unexpected
DNS leaks from that bug.
That's causing a whitelist operation to fail, so the DNS packets would
be blocked instead of leaked. I believe that's why the issue was flagged
as minor. Also if Linux netfilter had decided to route them in a leaky
way (send to eth0) they would be blocked by the forward-blocking
commands from the VPN doc anyway.
Chris
@Sec Tester:
I also checked for leaks using your "google method", but didn't
observe any except for the local IP which is a browser issue.
Glad to hear you got it done as well.
--
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/19d8efbc-337e-dffa-834e-f2e3fe529afe%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
