Qubes
/
gsoc


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239
							<html>
<head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Re: GSoC Port Forwarding</title>
<link rel="important stylesheet" href="">
<style>div.headerdisplayname {font-weight:bold;}
</style></head>
<body>
<table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part1"><tr><td><div class="headerdisplayname" style="display:inline;">Oggetto: </div>Re: GSoC Port Forwarding</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Mittente: </div>Giulio <giulio@gmx.com></td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>22/06/2021, 14:28</td></tr></table><table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part2"><tr><td><div class="headerdisplayname" style="display:inline;">A: </div>Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">CC: </div>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;</td></tr></table><br>
<div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode">Hello,
<br>thank you for the detailed response.
<br>
<br>Il 22/06/2021 04:43, Marek Marczykowski-Górecki ha scritto:
<br><blockquote type=cite style="color: #007cff;">Hi, I'm replying to both emails at once:
<br>
<br>On Sun, Jun 20, 2021 at 10:50:04PM +0200, Giulio wrote:
<br><blockquote type=cite style="color: #007cff;">Questions:
<br>
<br>1) Should we both support internal port forwarding and external port
<br>forwarding? Such as exposing a port for another domain or exposing a
<br>port through the public network interface? I would say yes.
<br></blockquote>
<br>Yes, I think so. Technically, those two cases should be quite similar.
<br>See also the case of sys-vpn much lower in the email.
<br>
<br></blockquote>
<br>I think that I'm actually failing to picture all the possible internal 
scenarios.
<br>
<br>1) In the case of external port forwarding &lt;sys-net&gt; should forward to 
&lt;sys-firewall&gt; and &lt;sys-firewall&gt; then to the &lt;appvm&gt;.
<br>In this case the port gets forwarded on the external interface ie: a LAN 
or a public ip address depending on the network environment.
<br>2) In the case of internal port forwarding, the port is forwarded only 
from &lt;sys-firewall&gt; to &lt;appvm&gt;. In that case, another &lt;appvm2&gt; can visit 
the &lt;appvm&gt; service using &lt;sys-firewall&gt; ip address and the chosen port.
<br>In this case, the ports get exposed on &lt;sys-firewall&gt; and thus depending 
on how the rules are implemented, may be available to all the AppVMs 
that share the same &lt;sys-firewall&gt;.
<br>
<br>In both cases may be important to allow to specify access rules for the 
forwarded port, such as the lan/public ip addresses ranges allowed for 
case 1 and the appvm name for case 2.
<br>
<br><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;">3) Since the expire= feature seems to be already implemented (and
<br>limited for the expiring full outgoing access) would it be useful to be
<br>implemented in gui and cli for every rule? I would say yes since the
<br>admin and agent code seems to be already there. The same goes for the
<br>"comment=" field.
<br></blockquote>
<br>Per-rule expire may be tricky to handle at the GUI level, I have no idea
<br>how to make the UI for this not very confusing...
<br>But the comment field is definitely useful to use.
<br>
<br></blockquote>
<br>How do you see the same checkbox that actually allows full internet 
access with the 5 minutes expiration time, displayed also on the window 
for adding a rule?
<br>However I think there is time to think more through this as the UI will 
be the last component.
<br>
<br><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;">4) How would you implement the management of forwarding rules in the
<br>network providing domain (sys-net)? Shall the user add a rule both in
<br>the target domain (ie the one with webserver and another one in sys-net)
<br>or should it be fully automatic from the first?
<br></blockquote>
<br>From the user point of view, I think it should be automated as much as
<br>possible. Like, let the user choose which port in which VM redirect to
<br>where. There may be cases when such redirection won't be possible - if
<br>there is no network path between the two points.
<br>
<br></blockquote>
<br>I agree with you. We might just check when the user adds an internal 
forwarding rule if both the source and the destination shares the same 
&lt;firewallvm&gt;, don't we?
<br>
<br>
<br><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;">5) Users should be able to set forward rules using domain names and not
<br>static ip addresses. In this case, the actual ip addresses of the dst
<br>domains should be collected in a similr way as currently DNS are
<br>resolved in `/core-agent-linux/qubesagent/firewall.py`, would this be good?
<br></blockquote>
<br>But here we are mostly talking about IP addresses of different VMs,
<br>right? Those can (and should) be resolved at core-admin side, so the VM
<br>applying the rules will have all the IP given. In fact VM may not be
<br>able to resolve IP of another VM at all.
<br>
<br></blockquote>
<br>Thanks for the insight, it totally makes sense.
<br>
<br><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;">Proposed XML Syntax:
<br>&lt;rule&gt;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&lt;properties&gt;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;property name="action"&gt;forward&lt;/property&gt;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;property name="proto"&gt;udp&lt;/property&gt;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;property name="dstports"&gt;443-8080-5555&lt;/property&gt;
<br>&nbsp;&nbsp;&nbsp;&nbsp;&lt;/properties&gt;
<br>&lt;rule&gt;
<br></blockquote>
<br>I don't see an important information here: forward to <span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>where<span class="moz-txt-tag">_</span></span>.
<br>
<br><blockquote type=cite style="color: #007cff;">Proposed Admin API Syntax:
<br>action=forward proto=udp dstports=443-8080-5555 [expire=&lt;unix
<br>timestamp&gt;] [comment=random text]
<br></blockquote>
<br>Similar here, there needs to be a forward target (IP, and possibly a
<br>port)
<br>
<br>On Tue, Jun 22, 2021 at 01:49:15AM +0200, Giulio wrote:
<br><blockquote type=cite style="color: #007cff;">Since in the case of port forwarding the target ip address would always be the &lt;vmname&gt; IP address,
<br></blockquote>
<br>This is very true. But there needs to be an information where to forward
<br>the traffic to (as noted earlier). Plus, possibly a second set of ports
<br>(if you want to redirect to a different port).
<br>
<br></blockquote>
<br>I am still failing to understand something here, could you give me a an 
example on when the dsthosts would different rather than the &lt;appvm&gt; or 
&lt;firewallvm&gt; ip?
<br>
<br>
<br><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;">I think my main concern now is the question 4 from the aforementioned
<br>email. Shall the rules be automatically implemented in all 3 involved
<br>vms? (&lt;netvm,firewallvm,appvm&gt;). I think yes, because otherwise it would
<br>be counterintuitive to be a partially manual and partially automatic
<br>operation. But since it actually 'automatically' exposes more attack
<br>surface, by loosening up all 3 vms network rules, I guess that maybe
<br>more reasoning on it would be helpful.
<br></blockquote>
<br>Yes, but you need to pass the traffic somehow. The direct connection can
<br>be achieved with qvm-connnect-tcp (connecting to the target directly
<br>using qrexec, bypassing intermediate VMs), but it has its limits (low
<br>performance, TCP only). To keep it as actual IP traffic, you need to
<br>change firewall rules at all intermediate VMs too.
<br>
<br>Lets have a specific example: in default setup, redirect TCP port 80
<br>from the outside, to 'work' VM port 8080.
<br>
<br>The setup looks like this:
<br>&nbsp;&nbsp; 
&nbsp;&nbsp; sys-net -&gt; sys-firewall -&gt; work
<br>
<br>For this, you will need those rules:
<br>
<br>1. In sys-net: forward TCP port 80 to sys-firewall
<br>2. In sys-firewall: forward TCP port 80 to work, port 8080
<br>3. In work: allow TCP port 8080
<br>
<br>Now is the important design question: how to store those rules? If you
<br>store them at all three places separately, it
<br>will be easier to apply them at runtime, but it will be harder to
<br>correlate them in UI. Plus, if any of them get modified/removed, it may
<br>be non-trivial to troubleshoot the issue.
<br>The other approach is to store the forward rules only in one place (the
<br>target, 'work' in this example? or the source, 'sys-net' here?). This
<br>way, it's harder to mess thing up. But when applying the rules (building
<br>rule sets for qubes-firewall service in all the involved VMs), you need
<br>to check several places.
<br>Plus, the UI should clearly show such redirected ports at all involved
<br>places, because it does affect system security - it must be easy to spot
<br>if any redirects are enabled.
<br>
<br>
<br>To make things more complex (sorry...), there may be a VPN or other
<br>proxy service (Tor?) involved. For example:
<br>
<br>sys-net -&gt; sys-firewall -&gt; sys-vpn -&gt; work
<br>
<br>In such a case, the "external" VM for 'work' is not really sys-net, but
<br>rather sys-vpn. And actually you need to be careful to not accidentally
<br>bypass VPN either by allowing 'work' to communicate outside of the VPN,
<br>or (maybe even worse) systems on the LAN (via sys-net) reach inside VPN.
<br>
<br>This case is not easy to solve, because currently core-admin has no idea
<br>whether sys-vpn (or other such VM) do any of such tunnelling. Maybe we
<br>need to (finally) introduce some flag to mark such VMs?
<br>
<br>
<br>And another question: what should happen if you change netvm of 'work'.
<br>For example switch to something like:
<br>
<br>&nbsp;&nbsp;&nbsp;&nbsp; sys-net -&gt; sys-firewall -&gt; (other VMs, but not 'work')
<br>
<br>&nbsp;&nbsp;&nbsp;&nbsp; sys-wifi -&gt; work
<br>
<br>Should the redirection stay active via sys-wifi? I think it should not,
<br>at least not automatically (maybe have an option for that?).
<br>
<br></blockquote>
<br>I understand all of your points and consequently it is hard to figure 
out a catch-all solution.
<br>
<br>I tried charting the flow of the possible solution.
<br><a class="moz-txt-link-freetext" href="https://git.lsd.cat/Qubes/gsoc/src/master/assets/implementation.png">https://git.lsd.cat/Qubes/gsoc/src/master/assets/implementation.png</a>
<br>
<br>As a sum up:
<br>1) Rules are stored only in &lt;appvm&gt;/firewall.xml
<br>2) Rules can either be internal or exteranl (ie: they are applied only 
to &lt;firewallvm&gt; or both to &lt;firewallvm&gt; and its &lt;netvm&gt;)
<br>3) Forwarding rules should be purged if &lt;appvm&gt; changes &lt;firewall&gt; 
(maybe also if &lt;firewallvm&gt; changes &lt;netvm&gt;? But that would be harde to 
detect I guess)
<br>4) Users should be able to specify both the forwarded port and 
destination port as you were saying
<br>5) Users should be able to eventually restrict forwarding to designated 
networks (with 0.0.0.0/0 being the wildcard instead of being a wildcard 
by default)
<br>
<br>However, in this case it will surely be harder to display the rules in 
all the affected vms.
<br>The other approach, as you were suggesting, of adding each specific rule 
in each vm conf does make sense, but I think then it would necessary 
something to keep track of the rule dependencies (such as a unique 
identifier). Furthermore there is a higher risk of having orphaned rules 
or a inconsistent state.
<br>
<br>Furthermore, in the "internal" vpn case that I have in mind, the idea is 
to forward the local port via the VPN interface or Tor (but in the Tor 
case users should just stick to Whonix). Some providers, such as 
Mullvad, AirVPN, PIA etc allows port forwarding this way and I think 
that's the most relevant case since it allows exposing a service on the 
internet while maintaining a bit of privacy/anonimity and whithout 
needing to bypass the local network NAT. Is this the same case you are 
referring to?
<br>
<br><blockquote type=cite style="color: #007cff;">And finally, don't forget IPv6 exists. Which means you can have the same
<br>port on IPv4 and IPv6. And theoretically they could be redirected to
<br>different places (but I'm not sure if that's a good idea...).
<br>
<br></blockquote>
<br>I think that once we have figured out the overall logic to implement, it 
should not be hard to duplicate it for ipv4/ipv6. I think the main 
problem to think about is to insert proper checks to prevent users from 
adding mixed rules.
<br>
<br>Cheers
<br>Giulio
<br></div></body>
</html>
</table></div>