On 11/12/2016 06:26 AM, David Hobach wrote:
> 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.
Assuming your VPN setup was not compromised the infrastructure being
used does not matter - even if it's potentially hostile (most of it
should actually be assumed to be hostile). Due to the beauties of
cryptography there's a tunnel between your proxy VM and your VPN exit
node as if there was a fixed line. And yes, your appvm using that
proxyVM can obviously find your VPN exit node IP by checking its IP
with whatever public service. And then what?
It cannot communicate outside of that tunnel as Qubes makes sure it
cannot use anything else than your proxy VPN VM; so I don't see how it
should identify your ISP IP address (except for maybe state-level
attacks such as netflow pattern analysis on a global scale).
If the VPN VM isn't internally restricting all forwarding, and VM
firewall settings (upstream proxyVM) is filtering by IP address, then a
compromised downstream appVM can send packets to the server IP that are
crafted to go around the tunnel. The most famous example of this is DNS
packets. People complain about them leaking all the time. On Qubes, DNS
is dnat-ed to a set address, but having this set properly depends on a
trigger from the VPN client... which may have failed. The system should
also be setup to prevent leaks if the VPN client fails, which could mean
that the client fails to set the default route or has a failure mode
that un-sets it.
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.
I fully agree that this more generic solution is better assuming it's
properly reviewed & maintained.
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.
Not 100% correct. Another address is whitelisted instead, namely that
of the netvm. So your DNS requests might go plain text through the
netvm (!= VPN --> leak) in the worst case. The things that help here
should be the routing table installed by openvpn, the DNS server
settings of your proxy VM & maybe the other iptables commands from the
VPN doc assuming a user manually implemented them, yes. So probably
only some further bugs in combination would lead to serious issues.
I see. So that is similar to the scenario I described above.
Chris
@Sec Tester:
AirVPN enables you to download the openVPN config files per VPN exit
node, i.e. switching should be as easy as writing some small bash
script to get it done on the command-line.
Alternatively they provide some generic config files by country which
apparently do the selection for you, i.e. by using one of these you
should also have some variety of exit nodes.
--
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/d8db5059-7221-fc35-33d1-df2b32504bd1%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
