Re: [Whonix-devel] VPN Fail Closed Mechanism - was: Development Discussion: Should Network Manager get installed by default?

[adrelanos <adr...@ri...>]

Vladimir Arseniev:
> On 04/02/2013 05:07 AM, adrelanos wrote:
>> Vladimir Arseniev:
>>>>> I've used it with network-manager-openvpn as VPN client, and it's very
>>>>> intuitive. But I'm not sure that I'd trust it managing Whonix's internal
>>>>> network interface.
>>>>
>>>> Well, in Whonix-Workstation case in worst case it leaks through Tor.
>>>>
>>>> Just expanded that page.
>>>>
>>>> Quote https://bugzilla.gnome.org/show_bug.cgi?id=689339#c4
>>>>
>>>>> "*Please also understand that currently networkmanager is not a
>>>> security tool at
>>>> all. VPN plugins are regarded as connectivity plugins, not security
>>>> plugins.*"
>>>>
>>>> Missing auto-reconnect feature:
>>>> https://bugzilla.gnome.org/show_bug.cgi?id=349151
>>>>
>>>> So perhaps using NM to set up VPNs for security isn't a good idea.
>>>>
>>>> Doesn't look like it has a fail closed mechanism:
>>>> https://sourceforge.net/p/whonix/wiki/VPN/#fail-closed-mechanism
>>>
>>> It's easy to install shorewall and rules that prevent leaks. See
>>> https://www.wilderssecurity.com/showthread.php?p=2201706#post2201706
>>
>> I don't think the following rule is very safe.
>>
>> # Allow this machine to connect to any server using UDP port 1194
>> [change if using TCP or other port]
>> ACCEPT  fw              net             udp     1194
> 
> True.
> 
> Those rules wouldn't stop a direct attack. But I think that they're good
> enough for preventing leaks caused by software misconfiguration, remote
> server failure and so on. I only use VPNs via Tor to access websites
> that block Tor exits, so the stakes aren't very high.
> 
>> Finally, I looked into the linux route command and tries to find a
>> solution for the VPN fail closed mechanism.
>>
>> The problem is, once the VPN breaks down, traffic will be send in the
>> clear (and in Whonix-Workstation case, "only" over Tor). Got started
>> with the solution...
>>
>> Check:
>> ip route show
>>
>> Stop applications which are not using proxy settings from using the
>> clearnet (or in Whonix-Workstation case, "only-Tor" fallback):
>> ip route del default via 192.168.0.10 dev eth0
>>
>> If you want to undo it:
>> ip route add default via 192.168.0.10 dev eth0
>> (or reboot)
>>
>> Perhaps adding a up script to configfile.openvpn could do it.
>> (up ip route del default via 192.168.0.10 dev eth0)
>>
>> In case of Whonix-Workstation many applications (ex: Tor Browser, wget,
>> curl...) are pre-configured to use a SocksPort (for stream isolation)
>> would still use "only-Tor". I recognize this must be quite confusing for
>> post-Tor-VPN users (user -> Tor -> VPN).
>>
>> There is still a route (sudo route) to 192.168.0.10 (Whonix-Gateway,
>> where Tor's SocksPorts are listening). Somehow I would have to configure
>> "the VPN may use 192.168.0.11, but nothing else". I don't know how to do
>> that.
> 
> I primarily use pfSense VMs as VPN clients. My latest setups are
> described in https://www.wilderssecurity.com/showthread.php?p=2209523.
> It's a long thread, I admit. There's also a first draft of a video
> tutorial at http://vimeo.com/mirimir/, but there's no sound yet :( There
> are both routing and firewall rules. In particular, the VPN tunnel is
> the only gateway for anything from LAN. I've killed the openvpn process
> in pfSense while streaming a video, and nothing from LAN gets out on
> pfSense WAN.
> 
>> Maybe I have very high security goals here. The goal is to rely on
>> OpenVPN to check if we're connected to the VPN server we expect and let
>> only OpenVPN connect to it and no other application.
>>
>> Using a firewall doesn't 100% enforce only using the VPN server. When
>> the IP of the VPN service gets assigned to another server, you could end
>> up connecting to a malicious server. Firewalls don't understand the VPN
>> authentication status, only OpenVPN does.
> 
> Isn't it likely that an adversary that could steal an IP address from a
> VPN server could simply just monitor traffic to that VPN server? You do
> have the server's ca.crt to authenticate it, so you won't connect.

Not sure. I could imagine that for the registrar of the IP addresses it
may be a bit simpler to steal and IP address than mounting MITM.

In any case, it's perhaps a minor issue. Still haven't totally wrapped
my head around it. It's risk of only OpenVPN connection to the spoofed
IP versus risk of any applications connecting to the spoofed IP.

>> Ultimately, having a dedicated VPN-Gateway may be the most secure
>> option. - If people can and want to pay the price (cpu, ram, disk
>> space). Having a dedicated Gateway is the only possibility to prevent
>> malware (with root) from deactivating the VPN* (to the extend of the
>> vulnerability resistance of the isolation box).
> 
> I go as far as pfSense VMs. I have at times run my networking VMs on
> different hosts from my workstation VMs. But then it becomes crucial to
> prevent unauthorized access to the switches ;)

>> Anyway, I could perhaps think about an iptables firewall designed to be
>> run inside Whonix-Workstation, which forbids any outgoing traffic from
>> users other than openvpn.
> 
> That sounds good.

I haven't found much on that topic, but...
http://www.inputoutput.io/hardening-your-vpn-setup-with-iptables/

May be a good starting point.