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 <marmarek@invisiblethingslab.com></td></tr><tr><td><div class="headerdisplayname" style="display:inline;">CC: </div>Frédéric Pierret <frederic.pierret@qubes-os.org></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 <sys-net> should forward to
- <sys-firewall> and <sys-firewall> then to the <appvm>.
- <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 <sys-firewall> to <appvm>. In that case, another <appvm2> can visit
- the <appvm> service using <sys-firewall> ip address and the chosen port.
- <br>In this case, the ports get exposed on <sys-firewall> and thus depending
- on how the rules are implemented, may be available to all the AppVMs
- that share the same <sys-firewall>.
- <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
- <firewallvm>, 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><rule>
- <br> <properties>
- <br> <property name="action">forward</property>
- <br> <property name="proto">udp</property>
- <br> <property name="dstports">443-8080-5555</property>
- <br> </properties>
- <br><rule>
- <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=<unix
- <br>timestamp>] [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 <vmname> 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 <appvm> or
- <firewallvm> 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? (<netvm,firewallvm,appvm>). 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>
- sys-net -> sys-firewall -> 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 -> sys-firewall -> sys-vpn -> 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> sys-net -> sys-firewall -> (other VMs, but not 'work')
- <br>
- <br> sys-wifi -> 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 <appvm>/firewall.xml
- <br>2) Rules can either be internal or exteranl (ie: they are applied only
- to <firewallvm> or both to <firewallvm> and its <netvm>)
- <br>3) Forwarding rules should be purged if <appvm> changes <firewall>
- (maybe also if <firewallvm> changes <netvm>? 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>
|