Re: [qubes-users] VPN-ProxyVM: "Leakproof VPN" by Rudd-O vs. "more involved" method in Qubes Wiki

2017-07-12 Thread Chris Laprise

On 07/12/2017 06:46 AM, Connor Page wrote:


after testing the 3 existing solutions I think the official command line
solution is t he most strict and protected.
I just don't get it why "sleep 2" is outside if statement in
qubes-user-firewall-script. why block all vpn traffic for 2 seconds
every time vms connect to or disconnect from the VPN vm?



The iptables command using --gid-owner won't recognize a system group 
immediately after the group is created, so a delay is necessary 
(otherwise the rule will be refused). Delay is outside the 'if' because 
rc.local and qubes-firewall run asynchronously to each other so it 
seemed appropriate to have it wait for either case. Of course, if this 
workaround fails in any way then traffic becomes blocked - so its safe.


You could get rid of the delay by adding the qvpn group to your template.

The gid-owner rule is there to satisfy an added requirement to block 
unintended non-VPN traffic coming from the proxyVM itself; it is not the 
main anti-leak feature (for downstream VMs).


BTW, I'm working on an update of the Qubes-VPN-support project (similar 
scripting to the doc) that runs as a systemd service. New version will 
have a simplified installer, which I will be posting in the next day or so:


https://github.com/tasket/Qubes-vpn-support

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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/4d76de3b-1dc5-586c-76d6-d614e0f041e0%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] VPN-ProxyVM: "Leakproof VPN" by Rudd-O vs. "more involved" method in Qubes Wiki

2017-07-12 Thread Connor Page
On Thursday, February 2, 2017, Chris Laprise  wrote:

> On 02/01/2017 07:36 PM, Connor Page wrote:
>
>> actually I think that reliance on mangle can be avoided since routing
>> table selection can be done by source address rather than firewall marks.
>> marks are good to differentiate different types of traffic but in our case
>> all traffic should be trated the same.
>> there is difference in how traffic from the vpn vm is routed. this leads
>> to two different attack vectors by a potentially compromised server. for
>> the official solution routing tables can be manipulated, for Rudd-O's tool
>> problems may arise from martian packets. some thought need to be given to
>> proper firewalling.
>>
>
> That's why I have iptables block according to the *interface*, which
> bypasses issues caused by odd routing. Anti-leak measures are best
> performed by watching below the IP layer.
>
> Chris
>

after testing the 3 existing solutions I think the official command line
solution is t he most strict and protected.
I just don't get it why "sleep 2" is outside if statement in
qubes-user-firewall-script. why block all vpn traffic for 2 seconds every
time vms connect to or disconnect from the VPN vm?

-- 
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/CAJ39Boo7r7yu%3DPo51SzmBJCokGH1A75Pa1gx-%2BksC%3DPBP9_J1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] VPN-ProxyVM: "Leakproof VPN" by Rudd-O vs. "more involved" method in Qubes Wiki

2017-02-01 Thread Connor Page
actually I think that reliance on mangle can be avoided since routing table 
selection can be done by source address rather than firewall marks. marks are 
good to differentiate different types of traffic but in our case all traffic 
should be trated the same.
there is difference in how traffic from the vpn vm is routed. this leads to two 
different attack vectors by a potentially compromised server. for the official 
solution routing tables can be manipulated, for Rudd-O's tool problems may 
arise from martian packets. some thought need to be given to proper firewalling.

-- 
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/6603fa95-46f6-488b-8b90-13ee95543c18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] VPN-ProxyVM: "Leakproof VPN" by Rudd-O vs. "more involved" method in Qubes Wiki

2017-02-01 Thread Chris Laprise

On 02/01/2017 08:06 AM, Connor Page wrote:

relying on the main routing table that can be messed up.


This point tends to be overstated. I haven't seen an example of the 
blocking commands in the routing table getting "messed up". The commands 
get refreshed each and every time qubes-firewall makes a change, and the 
fact they are managed along with all the other Qubes firewall rules 
should be seen as a plus. For a VM environment that is dedicated to a 
specific purpose (no extra firewall-management services configured) the 
subject is moot.


IIRC, the other solution relies on the integrity of 'mangle' table to 
make the custom chain work. I'm not saying that's a bad choice, but its 
not inherently better.



  However, that requires relaxing the reverse path filter and I don't remember 
any mitigation for potential attacks by VPN servers exploiting this.
The main advantage is that an rpm package is produced so there's an easy way 
for creating and maintaining multiple VPN VMs based on the same template = 
easier updates.



Chris

--
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/766de2de-6ca8-869f-afa3-822e9ed6112a%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] VPN-ProxyVM: "Leakproof VPN" by Rudd-O vs. "more involved" method in Qubes Wiki

2017-02-01 Thread Connor Page
Rudd-O's solution uses a separate routing table thus ensuring that all traffic 
from VMs go either to VPN or a "blackhole". This is more robust than relying on 
the main routing table that can be messed up. However, that requires relaxing 
the reverse path filter and I don't remember any mitigation for potential 
attacks by VPN servers exploiting this.
The main advantage is that an rpm package is produced so there's an easy way 
for creating and maintaining multiple VPN VMs based on the same template = 
easier updates.

-- 
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/1b7aff2c-c714-4520-a45c-b14314192c10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] VPN-ProxyVM: "Leakproof VPN" by Rudd-O vs. "more involved" method in Qubes Wiki

2017-02-01 Thread mittendorf
Hello fellow Qubes users,

I am aware of two ways o achive a "leakproof" VPN-ProxyVM.

The sollution by Rudd-O
https://github.com/Rudd-O/qubes-vpn

and the "more involved" method in the Qubes wiki

https://www.qubes-os.org/doc/vpn/

both with anti-leak preventive measures and both based on OpenVPN.

Questions:
- are the different or is Rudd-Os tool "just" a user-friendly interface
for the same method?
- If not, which method do you prefer and why?

thanks

-- 
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/235945b3-5993-93b4-7d85-a372f368f335%40digitrace.de.
For more options, visit https://groups.google.com/d/optout.