Menu
▾
▴
whonix-devel — Whonix Development Public Mailing List
You can subscribe to this list here.
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2013 |
Jan
(4) |
Feb
(4) |
Mar
(38) |
Apr
(19) |
May
(25) |
Jun
(23) |
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: chiccofx <chi...@to...> - 2013-05-08 00:43:04
|
Hello Everybody, I am a new user to whonix, but an experienced *nix developer. I have read the faq about the question related with openbsd and security. I want volunteer myself to address many of those issues. There have been some recent developments on the issues pointed by the faq. Openbsd as a whonix gateway would not only decrease the attack surface, but the VM would required even less RAM than what is used currently. This would improve the overall user experience and allow more RAM to be assigned to the whonix workstation by default. Let me know what are your thoughts on this. I am planning to replace my current debian whonix gateway with an OpenBSD 5.3 (launched May 1) and see how it perform. Happy to share the result. Thank you, -- GPG: 12E9 BCD6 5298 70B5 6C4C 7F1C 8C70 D6ED 188C AACE |
|
From: <adr...@ri...> - 2013-05-01 01:32:52
|
This is only interesting for VPN users. VPN's generally fail open. VPN servers and VPN software can occasionally break down without announcement. This means, if the VPN is unreachable, connections breaks down for whatever reasons and so on, in most cases, you can continue to connect to the internet without the VPN. Unless you are only using the VPN to circumvent censorship and not because you believe you're safer because of any (additional) VPN, this is most likely something you want to prevent. This is not a Whonix specific problem. It is a general problem with VPNs. Most users are simply not aware of it. There are some blog posts about this topic, but no real Open Source / Free Software project supporting Linux. Therefore the VPN-Firewall project has been created by adrelanos (Whonix maintainer), providing tight firewall rules to prevent connecting to any other servers than the VPN server and to load the firewall before the network, so it's ensured, that all traffic goes through the VPN. If that's of interest to you, carefully check out the VPN-Firewall project page: [https://github.com/adrelanos/VPN-Firewall](https://github.com/adrelanos/VPN-Firewall) URL: http://sourceforge.net/p/whonix/featureblog/2013/05/vpn-firewall---leak-protection-fail-safe-mechanism-for-openvpn/ |
|
From: <adr...@ri...> - 2013-04-29 17:51:16
|
(This is a general issue. Not an issue caused by Whonix.) Using a VPN or SSH neither doesn't provide strong guarantees of hiding your the fact you are using Tor from your ISP. VPN's and SSH's are vulnerable to an attack called Website traffic fingerprinting ^5^. Very briefly, it's a passive eavesdropping attack, although the adversary only watches encrypted traffic from the VPN or SSH, the adversary can still guess what website is being visited, because all websites have specific traffic patterns. The content of the transmission is still hidden, but to which website one connects to isn't secret anymore. There are multiple research papers on that topic. ^6^ Once the premise is accepted, that VPN's and SSH's can leak which website one is visiting with a high accuracy, it's not difficult to imagine, that also encrypted Tor traffic hidden by a VPN's or SSH's could be classified. There are no research papers on that topic. As another issue that may apply, people who need to hide Tor, may also not want to be associated with other encrypted traffic such as traffic from VPN's or SSH's. So in many cases, recommending another kind of encrypted traffic (VPN or SSH) to hide encrypted traffic one wants to hide (Tor), isn't an applicable advice. Traffic stenography; private and obfuscated bridges as an maybe alternative method, have their own blog post. [5] ^5^ See Tor Browser Design [1] for a general definition and introduction into Website traffic fingerprinting. ^6^ See slides for Touching from a Distance: Website Fingerprinting Attacks and Defenses [2]. There is also a research paper [3] from those authors. Unfortunately, it's not free. However, you can find free ones using search engines. Good search terms include "Website Fingerprinting VPN". You'll find multiple research papers on that topic. The article "Hide the fact, that you are using Tor/Whonix" has been updated with this information. [4] [1] [https://www.torproject.org/projects/torbrowser/design/](https://www.torproject.org/projects/torbrowser/design/) [2] [http://www.cs.sunysb.edu/~xcai/fp.pdf](http://www.cs.sunysb.edu/~xcai/fp.pdf) [3] [https://dl.acm.org/citation.cfm?id=2382260](https://dl.acm.org/citation.cfm?id=2382260) [4] [https://sourceforge.net/p/whonix/wiki/Hide%20Tor%20and%20Whonix%20from%20your%20ISP/](https://sourceforge.net/p/whonix/wiki/Hide%20Tor%20and%20Whonix%20from%20your%20ISP/) [5] [https://sourceforge.net/p/whonix/featureblog/2013/04/private-and-obfuscated-bridges-not-so-good-for-hiding-tor/](https://sourceforge.net/p/whonix/featureblog/2013/04/private-and-obfuscated-bridges-not-so-good-for-hiding-tor/) URL: http://sourceforge.net/p/whonix/featureblog/2013/04/vpns-and-sshs-not-as-good-for-hiding-tor-traffic/ |
|
From: <adr...@ri...> - 2013-04-29 17:50:57
|
(This is a general issue. Not an issue caused by Whonix.) Using private and obfuscated bridges alone doesn't provide strong guarantees of hiding your the fact you are using Tor from your ISP. Quote [1] (w [2]) Jacob Appelbaum: > "Some pluggable transports may seek to obfuscate traffic or to morph it. However, they do not claim to hide that you are using Tor in all cases but rather in very specific cases. An example threat model includes a DPI device with limited time to make a classification choice - so the hiding is very specific to functionality and generally does not take into account endless data retention with retroactive policing." I agree. It's an arms race. The goal of the user is to hide the fact, being a Tor user. The goal of the adversary is to find out who is using Tor by passively logging all (or reasonable portions) of traffic. Even if a private and obfuscated (pluggable transports) bridge is trustworthy and there are at the moment no known weaknesses in the traffic obfuscation, time plays for of the adversary. Once a weakness has been found, all traffic can be retrospectively classified as Tor traffic. Updated and improved pluggable transports enable users again with censorship circumvention, users already known to have used Tor however, will still be known. [1] [https://mailman.boum.org/pipermail/tails-dev/2013-April/002950.html](https://mailman.boum.org/pipermail/tails-dev/2013-April/002950.html) [2] [http://www.webcitation.org/6G67ltL45](http://www.webcitation.org/6G67ltL45) URL: http://sourceforge.net/p/whonix/featureblog/2013/04/private-and-obfuscated-bridges-not-so-good-for-hiding-tor/ |
|
From: <adr...@ri...> - 2013-04-21 09:39:07
|
Whonix-Workstation: * Using Boot Clock Randomization (Whonix 0.6.2 and above), i.e. after boot, the clock is set randomly between 5 and 180 seconds into the past or future. This is useful to enforce the design goal, that the host clock and Whonix-Workstation clock should always slightly differ. It's also useful to obfuscate the clock when tails_htp itself is running, because naturally at this time, tails_htp hasn't finished. Whonix-Gateway: * Doesn't use Boot Clock Randomization. If the assumption is correct, that the ISP can detect clock jumps by observing Tor's TLS client hello, clock jumps should be avoided to prevent fingerprinting Whonix users. URL: http://sourceforge.net/p/whonix/featureblog/2013/04/boot-clock-randomization---the-timesync-design-updated/ |
|
From: <adr...@ri...> - 2013-04-09 18:49:05
|
I finally wrote down some notes about Chaining Anonymizing Gateways. Added to Advanced Security Guide. [https://sourceforge.net/p/whonix/wiki/Advanced%20Security%20Guide/#chaining-anonymizing-gateways](https://sourceforge.net/p/whonix/wiki/Advanced%20Security%20Guide/#chaining-anonymizing-gateways) URL: http://sourceforge.net/p/whonix/featureblog/2013/04/experts-only-new-chapter---chaining-anonymizing-gateways/ |
|
From: <adr...@ri...> - 2013-04-08 17:56:10
|
In hope this gets retweeted/reposted. [http://whonix.sourceforge.net/screenshots/Whonix-ad.png](http://whonix.sourceforge.net/screenshots/Whonix-ad.png)  Have any idea how to improve Whonix and want to do it? You could also check the Feature/Bug tracker. [https://sourceforge.net/p/whonix/awiki/Dev/](https://sourceforge.net/p/whonix/awiki/Dev/) And pick a task which interests you most, or ask for the most important or most suitable one for you. There are some tasks which require discussion, ideas, thoughts or only documentation, others require research or communication with upstream, some are ready to get implemented and are waiting for code. URL: http://sourceforge.net/p/whonix/featureblog/2013/04/looking-for-developers/ |
|
From: <adr...@ri...> - 2013-04-08 17:55:57
|
...from torproject.org wiki to sf.net wiki: [https://sourceforge.net/p/whonix/awiki/Dev/](https://sourceforge.net/p/whonix/awiki/Dev/) This is a temporary solution until a host / bug tracker has been found, which is really difficult: [https://sourceforge.net/p/whonix/wiki/About](https://sourceforge.net/p/whonix/wiki/About) Infrastructure/ Nevertheless, it's an improvement, because now anyone can edit and no additional account for torproject.org wiki is required. URL: http://sourceforge.net/p/whonix/featureblog/2013/04/bugfeature-tracker-moved/ |
|
From: adrelanos <adr...@ri...> - 2013-04-02 20:02:26
|
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. |
|
From: Vladimir A. <vla...@ap...> - 2013-04-02 07:28:07
|
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. > 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. > ------------------------------------------------------------------------------ > Own the Future-Intel(R) Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. Compete > for recognition, cash, and the chance to get your game on Steam. > $5K grand prize plus 10 genre and skill prizes. Submit your demo > by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 > _______________________________________________ > Whonix-devel mailing list > Who...@li... > https://lists.sourceforge.net/lists/listinfo/whonix-devel > |
|
From: adrelanos <adr...@ri...> - 2013-04-02 01:07:46
|
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 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. 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. 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). 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. |
|
From: Vladimir A. <vla...@ap...> - 2013-04-01 19:50:58
|
On 04/01/2013 05:31 PM, adrelanos wrote: > Vladimir Arseniev: >> On 04/01/2013 04:05 AM, adr...@ri... wrote: >>> [https://sourceforge.net/p/whonix/wiki/Dev_NetworkManager/](https://sourceforge.net/p/whonix/wiki/Dev_NetworkManager/) >>> >>> URL: http://sourceforge.net/p/whonix/featureblog/2013/04/development-discussion-should-network-manager-get-installed-by-default/ >> >> It's my impression that network manager (in Ubuntu etc, at least) may >> alter various networking settings in order to maintain connectivity. > > Yes, but not if they are configured with ifupdown in > /etc/network/interfaces. According to 13.04 man page > http://manpages.ubuntu.com/manpages/precise/en/man5/NetworkManager.conf.5.html > (ifupdown plugin) it's still not planed. > > I believe you mean, that NM can create, manage etc. new interfaces, but > they won't write into /etc/network/interfaces and won't involve > ifupdown, it uses it's own configuration files. Good :) >> 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 |
|
From: adrelanos <adr...@ri...> - 2013-04-01 13:31:58
|
Vladimir Arseniev: > On 04/01/2013 04:05 AM, adr...@ri... wrote: >> [https://sourceforge.net/p/whonix/wiki/Dev_NetworkManager/](https://sourceforge.net/p/whonix/wiki/Dev_NetworkManager/) >> >> URL: http://sourceforge.net/p/whonix/featureblog/2013/04/development-discussion-should-network-manager-get-installed-by-default/ > > It's my impression that network manager (in Ubuntu etc, at least) may > alter various networking settings in order to maintain connectivity. Yes, but not if they are configured with ifupdown in /etc/network/interfaces. According to 13.04 man page http://manpages.ubuntu.com/manpages/precise/en/man5/NetworkManager.conf.5.html (ifupdown plugin) it's still not planed. I believe you mean, that NM can create, manage etc. new interfaces, but they won't write into /etc/network/interfaces and won't involve ifupdown, it uses it's own configuration files. > 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 |
|
From: Vladimir A. <vla...@ap...> - 2013-04-01 05:31:34
|
On 04/01/2013 04:05 AM, adr...@ri... wrote: > [https://sourceforge.net/p/whonix/wiki/Dev_NetworkManager/](https://sourceforge.net/p/whonix/wiki/Dev_NetworkManager/) > > URL: http://sourceforge.net/p/whonix/featureblog/2013/04/development-discussion-should-network-manager-get-installed-by-default/ It's my impression that network manager (in Ubuntu etc, at least) may alter various networking settings in order to maintain connectivity. 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. |
|
From: <adr...@ri...> - 2013-04-01 00:05:21
|
New chapter for a post-Tor-VPNs (user -> Tor -> VPN) setting up using the graphical Network Manager. For advanced users. [https://sourceforge.net/p/whonix/wiki/TestVPN/#using-a-graphical-user-interface](https://sourceforge.net/p/whonix/wiki/TestVPN/#using-a-graphical-user-interface) URL: http://sourceforge.net/p/whonix/featureblog/2013/03/setting-up-vpn-in-whonix-workstation-using-graphical-network-manager-967/ |
|
From: <adr...@ri...> - 2013-04-01 00:05:14
|
New chapter for a post-Tor VPN (user -> Tor -> VPN) using graphical Network Manager for advanced users. [https://sourceforge.net/p/whonix/wiki/TestVPN/#using-a-graphical-user-interface](https://sourceforge.net/p/whonix/wiki/TestVPN/#using-a-graphical-user-interface) URL: http://sourceforge.net/p/whonix/featureblog/2013/03/setting-up-vpn-in-whonix-workstation-using-graphical-network-manager/ |
|
From: adrelanos <adr...@ri...> - 2013-03-30 19:51:16
|
Vladimir Arseniev: > On 03/30/2013 02:59 PM, adrelanos wrote: >> Vladimir Arseniev: >>>>> Another question occurs to me. How hard would it be to "add" (in some way) >>>>>>> all Whonix workstation "stuff" to an existing Debian VM? >>>>> >>>>> Not very hard. >>>>> Same instructions as: >>>>> https://sourceforge.net/p/whonix/wiki/PhysicalIsolation/#install-whonix-workstation-on-hardware-untested-not-recommend >>> I can be dense at times :( > > I meant that I wasn't reading carefully, and was preoccupied. > >> I don't understand. Should I elaborate on how to do that? > > Before you take time for that, how about I try it, and post my experience? I am happy about any test results. |
|
From: Vladimir A. <vla...@ap...> - 2013-03-30 17:20:02
|
On 03/30/2013 02:59 PM, adrelanos wrote: > Vladimir Arseniev: >>>> Another question occurs to me. How hard would it be to "add" (in some way) >>>>>> all Whonix workstation "stuff" to an existing Debian VM? >>>> >>>> Not very hard. >>>> Same instructions as: >>>> https://sourceforge.net/p/whonix/wiki/PhysicalIsolation/#install-whonix-workstation-on-hardware-untested-not-recommend >> I can be dense at times :( I meant that I wasn't reading carefully, and was preoccupied. > I don't understand. Should I elaborate on how to do that? Before you take time for that, how about I try it, and post my experience? |
|
From: adrelanos <adr...@ri...> - 2013-03-30 11:00:00
|
Vladimir Arseniev: >>> Another question occurs to me. How hard would it be to "add" (in some way) >>> >> all Whonix workstation "stuff" to an existing Debian VM? >> > >> > Not very hard. >> > Same instructions as: >> > https://sourceforge.net/p/whonix/wiki/PhysicalIsolation/#install-whonix-workstation-on-hardware-untested-not-recommend > I can be dense at times :( > I don't understand. Should I elaborate on how to do that? |
|
From: Vladimir A. <vla...@ap...> - 2013-03-30 07:23:55
|
On 03/29/2013 01:34 PM, adrelanos wrote: > Vladimir Arseniev: >> On 03/28/2013 03:24 PM, adrelanos wrote: >> >>> Vladimir Arseniev: >>>> On 03/28/2013 12:15 AM, adr...@ri... wrote: <snip> >>> Whonix-Workstation on hardware with physical isolation without VMs: >>> - Installing Debain is as easy/hard as without Whonix. >>> - Installing Whonix isn't that hard: >>> > https://sourceforge.net/p/whonix/wiki/PhysicalIsolation/#install-whonix-workstation-on-hardware-untested-not-recommend >> >> OK, I'll look at this. > > This might also solve your other question "How hard would it be to "add" > (in some way) all Whonix workstation "stuff" to an existing Debian VM?". Yes, indeed :) <snip> >> Another question occurs to me. How hard would it be to "add" (in some way) >> all Whonix workstation "stuff" to an existing Debian VM? > > Not very hard. > Same instructions as: > https://sourceforge.net/p/whonix/wiki/PhysicalIsolation/#install-whonix-workstation-on-hardware-untested-not-recommend I can be dense at times :( >>>> I write that as someone who uses the Debian alternate installer for LUKS >>>> setup. >>> >>> Yes, it's not as easy as using TrueCrypt FDE on Windows. >> >> Actually, RAID/LUKS/LVM with the Debian alternate installer is far, far >> easier than TrueCrypt FDE on Windows ;) > > Well, that's open for debate. Does the Debian alternate installer > encrypt swap by default? I find the Windows user interface of TrueCrypt > much easier to grasp. I should have said "far, far easier for me" :) Well, "default" isn't relevant if you're doing RAID, because you configure the partitions manually. But the "wizards", albeit rudimentary, are very flexible. Anyway, in my typical setup, swap, root and home are all volumes in LVM, and the LVM group lives on a LUKS encrypted partition on a ~2TB RAID10 array. So boot (on its own ~300MB RAID10 array) is the only thing that's not encrypted. |
1 message has been excluded from this view by a project administrator.
){kind=link}