395 lines
29 KiB
HTML
Executable File
395 lines
29 KiB
HTML
Executable File
<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>Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com></td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Data: </div>22/06/2021, 16:04</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>Giulio <giulio@gmx.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-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode"><pre wrap class="moz-quote-pre">
|
|
On Tue, Jun 22, 2021 at 02:28:26PM +0200, Giulio wrote:
|
|
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> </span>Hello,
|
|
<span class="moz-txt-citetags">> </span>thank you for the detailed response.
|
|
<span class="moz-txt-citetags">> </span>
|
|
<span class="moz-txt-citetags">> </span>Il 22/06/2021 04:43, Marek Marczykowski-Górecki ha scritto:
|
|
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > </span>Hi, I'm replying to both emails at once:
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>On Sun, Jun 20, 2021 at 10:50:04PM +0200, Giulio wrote:
|
|
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > > </span>Questions:
|
|
<span class="moz-txt-citetags">> > > </span>
|
|
<span class="moz-txt-citetags">> > > </span>1) Should we both support internal port forwarding and external port
|
|
<span class="moz-txt-citetags">> > > </span>forwarding? Such as exposing a port for another domain or exposing a
|
|
<span class="moz-txt-citetags">> > > </span>port through the public network interface? I would say yes.
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>Yes, I think so. Technically, those two cases should be quite similar.
|
|
<span class="moz-txt-citetags">> > </span>See also the case of sys-vpn much lower in the email.
|
|
<span class="moz-txt-citetags">> > </span>
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> </span>
|
|
<span class="moz-txt-citetags">> </span>I think that I'm actually failing to picture all the possible internal
|
|
<span class="moz-txt-citetags">> </span>scenarios.
|
|
<span class="moz-txt-citetags">> </span>
|
|
<span class="moz-txt-citetags">> </span>1) In the case of external port forwarding <sys-net> should forward to
|
|
<span class="moz-txt-citetags">> </span><sys-firewall> and <sys-firewall> then to the <appvm>.
|
|
<span class="moz-txt-citetags">> </span>In this case the port gets forwarded on the external interface ie: a LAN
|
|
<span class="moz-txt-citetags">> </span>or a public ip address depending on the network environment.
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
|
|
Yes.
|
|
|
|
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> </span>2) In the case of internal port forwarding, the port is forwarded only
|
|
<span class="moz-txt-citetags">> </span>from <sys-firewall> to <appvm>. In that case, another <appvm2> can visit
|
|
<span class="moz-txt-citetags">> </span>the <appvm> service using <sys-firewall> ip address and the chosen port.
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
|
|
Yes.
|
|
|
|
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> </span>In this case, the ports get exposed on <sys-firewall> and thus depending
|
|
<span class="moz-txt-citetags">> </span>on how the rules are implemented, may be available to all the AppVMs
|
|
<span class="moz-txt-citetags">> </span>that share the same <sys-firewall>.
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
|
|
Yes.
|
|
|
|
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> </span>In both cases may be important to allow to specify access rules for the
|
|
<span class="moz-txt-citetags">> </span>forwarded port, such as the lan/public ip addresses ranges allowed for
|
|
<span class="moz-txt-citetags">> </span>case 1 and the appvm name for case 2.
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
|
|
Yes, indeed.
|
|
|
|
</pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > > </span>3) Since the expire= feature seems to be already implemented (and
|
|
<span class="moz-txt-citetags">> > > </span>limited for the expiring full outgoing access) would it be useful to be
|
|
<span class="moz-txt-citetags">> > > </span>implemented in gui and cli for every rule? I would say yes since the
|
|
<span class="moz-txt-citetags">> > > </span>admin and agent code seems to be already there. The same goes for the
|
|
<span class="moz-txt-citetags">> > > </span>"comment=" field.
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>Per-rule expire may be tricky to handle at the GUI level, I have no idea
|
|
<span class="moz-txt-citetags">> > </span>how to make the UI for this not very confusing...
|
|
<span class="moz-txt-citetags">> > </span>But the comment field is definitely useful to use.
|
|
<span class="moz-txt-citetags">> > </span>
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> </span>
|
|
<span class="moz-txt-citetags">> </span>How do you see the same checkbox that actually allows full internet
|
|
<span class="moz-txt-citetags">> </span>access with the 5 minutes expiration time, displayed also on the window
|
|
<span class="moz-txt-citetags">> </span>for adding a rule?
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
|
|
This may be more relevant to longer times. With times like 5min, just
|
|
setting the rules up (if you want more than one of them) may already eat
|
|
up significant portion of the expiration time...
|
|
|
|
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> </span>However I think there is time to think more through this as the UI will
|
|
<span class="moz-txt-citetags">> </span>be the last component.
|
|
<span class="moz-txt-citetags">> </span>
|
|
</pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > > </span>4) How would you implement the management of forwarding rules in the
|
|
<span class="moz-txt-citetags">> > > </span>network providing domain (sys-net)? Shall the user add a rule both in
|
|
<span class="moz-txt-citetags">> > > </span>the target domain (ie the one with webserver and another one in sys-net)
|
|
<span class="moz-txt-citetags">> > > </span>or should it be fully automatic from the first?
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>From the user point of view, I think it should be automated as much as
|
|
<span class="moz-txt-citetags">> > </span>possible. Like, let the user choose which port in which VM redirect to
|
|
<span class="moz-txt-citetags">> > </span>where. There may be cases when such redirection won't be possible - if
|
|
<span class="moz-txt-citetags">> > </span>there is no network path between the two points.
|
|
<span class="moz-txt-citetags">> > </span>
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> </span>
|
|
<span class="moz-txt-citetags">> </span>I agree with you. We might just check when the user adds an internal
|
|
<span class="moz-txt-citetags">> </span>forwarding rule if both the source and the destination shares the same
|
|
<span class="moz-txt-citetags">> </span><firewallvm>, don't we?
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
|
|
I think we can simplify it even further: allow forwarding ports only
|
|
from (any of) upstream VMs. For example in this case:
|
|
|
|
appvm1 -> sys-firewall -> sys-net
|
|
| |
|
|
appvm2 ------+ |
|
|
|
|
|
appvm3 -> some-other-firewall -+
|
|
|
|
Allow forwarding to appvm1 only from sys-net (external case) or
|
|
sys-firwall, but not appvm3 or some-other-firewall.
|
|
Then, within the forward rule configuration you can restrict access
|
|
rules (like you propose below, with default 0.0.0.0/0). This restriction
|
|
will work for VMs directly connected to sys-firewall only, because there
|
|
is NAT (sys-net does not know whether its appvm1 or appvm2 - it only
|
|
sees sys-firewall IP in those cases). But I think it's ok to make this
|
|
limitation and require VMs to be connected to the same <firewallvm> if
|
|
you want to forward traffic between them.
|
|
|
|
I think you did it right with the internal/external type.
|
|
|
|
Allowing forwarding from others (like some-other-firewall in the picture
|
|
above) may be tricky (and unreliable), as it will be hard to restrict
|
|
who can really connect (sys-net have no idea which VM behind
|
|
sys-firewall/some-other-firewall really connects).
|
|
|
|
</pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > > </span>5) Users should be able to set forward rules using domain names and not
|
|
<span class="moz-txt-citetags">> > > </span>static ip addresses. In this case, the actual ip addresses of the dst
|
|
<span class="moz-txt-citetags">> > > </span>domains should be collected in a similr way as currently DNS are
|
|
<span class="moz-txt-citetags">> > > </span>resolved in `/core-agent-linux/qubesagent/firewall.py`, would this be good?
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>But here we are mostly talking about IP addresses of different VMs,
|
|
<span class="moz-txt-citetags">> > </span>right? Those can (and should) be resolved at core-admin side, so the VM
|
|
<span class="moz-txt-citetags">> > </span>applying the rules will have all the IP given. In fact VM may not be
|
|
<span class="moz-txt-citetags">> > </span>able to resolve IP of another VM at all.
|
|
<span class="moz-txt-citetags">> > </span>
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> </span>
|
|
<span class="moz-txt-citetags">> </span>Thanks for the insight, it totally makes sense.
|
|
<span class="moz-txt-citetags">> </span>
|
|
</pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > > </span>Proposed XML Syntax:
|
|
<span class="moz-txt-citetags">> > > </span><rule>
|
|
<span class="moz-txt-citetags">> > > </span> <properties>
|
|
<span class="moz-txt-citetags">> > > </span> <property name="action">forward</property>
|
|
<span class="moz-txt-citetags">> > > </span> <property name="proto">udp</property>
|
|
<span class="moz-txt-citetags">> > > </span> <property name="dstports">443-8080-5555</property>
|
|
<span class="moz-txt-citetags">> > > </span> </properties>
|
|
<span class="moz-txt-citetags">> > > </span><rule>
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>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>.
|
|
<span class="moz-txt-citetags">> > </span>
|
|
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > > </span>Proposed Admin API Syntax:
|
|
<span class="moz-txt-citetags">> > > </span>action=forward proto=udp dstports=443-8080-5555 [expire=<unix
|
|
<span class="moz-txt-citetags">> > > </span>timestamp>] [comment=random text]
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>Similar here, there needs to be a forward target (IP, and possibly a
|
|
<span class="moz-txt-citetags">> > </span>port)
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>On Tue, Jun 22, 2021 at 01:49:15AM +0200, Giulio wrote:
|
|
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > > </span>Since in the case of port forwarding the target ip address would always be the <vmname> IP address,
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>This is very true. But there needs to be an information where to forward
|
|
<span class="moz-txt-citetags">> > </span>the traffic to (as noted earlier). Plus, possibly a second set of ports
|
|
<span class="moz-txt-citetags">> > </span>(if you want to redirect to a different port).
|
|
<span class="moz-txt-citetags">> > </span>
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> </span>
|
|
<span class="moz-txt-citetags">> </span>I am still failing to understand something here, could you give me a an
|
|
<span class="moz-txt-citetags">> </span>example on when the dsthosts would different rather than the <appvm> or
|
|
<span class="moz-txt-citetags">> </span><firewallvm> ip?
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
|
|
I'm talking about the other end of the connection. Let me summarize
|
|
this for different rules:
|
|
|
|
1. For allow/deny rules, it is about where the VM can connect to -
|
|
outgoing connection. The source IP is always the VM's IP (implicitly),
|
|
and the rule can specify destination IP, protocol, port.
|
|
|
|
2. For forward rules, it is about incoming connection - the destination
|
|
IP is VM's IP (implicitly), but then the connection is redirected to
|
|
somewhere else (like some appvm) - and the rule needs to point out to
|
|
where it should redirect.
|
|
|
|
If you have simplified case like this:
|
|
|
|
sys-net -> appvm
|
|
|
|
Then, the rule in sys-net not only needs to know what to redirect (like,
|
|
TCP port 80), but also needs to know to redirect it to appvm, not
|
|
anywhere else.
|
|
Similarly, if the rule is stored with appvm, it needs to know to
|
|
install the redirect in sys-net and not some intermediate other VM (as
|
|
talked about internal, or VPN or Tor cases).
|
|
|
|
Ok, reading your response further, I think you covered it with
|
|
external/internal type, so it should be good.
|
|
|
|
</pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > > </span>I think my main concern now is the question 4 from the aforementioned
|
|
<span class="moz-txt-citetags">> > > </span>email. Shall the rules be automatically implemented in all 3 involved
|
|
<span class="moz-txt-citetags">> > > </span>vms? (<netvm,firewallvm,appvm>). I think yes, because otherwise it would
|
|
<span class="moz-txt-citetags">> > > </span>be counterintuitive to be a partially manual and partially automatic
|
|
<span class="moz-txt-citetags">> > > </span>operation. But since it actually 'automatically' exposes more attack
|
|
<span class="moz-txt-citetags">> > > </span>surface, by loosening up all 3 vms network rules, I guess that maybe
|
|
<span class="moz-txt-citetags">> > > </span>more reasoning on it would be helpful.
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>Yes, but you need to pass the traffic somehow. The direct connection can
|
|
<span class="moz-txt-citetags">> > </span>be achieved with qvm-connnect-tcp (connecting to the target directly
|
|
<span class="moz-txt-citetags">> > </span>using qrexec, bypassing intermediate VMs), but it has its limits (low
|
|
<span class="moz-txt-citetags">> > </span>performance, TCP only). To keep it as actual IP traffic, you need to
|
|
<span class="moz-txt-citetags">> > </span>change firewall rules at all intermediate VMs too.
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>Lets have a specific example: in default setup, redirect TCP port 80
|
|
<span class="moz-txt-citetags">> > </span>from the outside, to 'work' VM port 8080.
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>The setup looks like this:
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span> sys-net -> sys-firewall -> work
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>For this, you will need those rules:
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>1. In sys-net: forward TCP port 80 to sys-firewall
|
|
<span class="moz-txt-citetags">> > </span>2. In sys-firewall: forward TCP port 80 to work, port 8080
|
|
<span class="moz-txt-citetags">> > </span>3. In work: allow TCP port 8080
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>Now is the important design question: how to store those rules? If you
|
|
<span class="moz-txt-citetags">> > </span>store them at all three places separately, it
|
|
<span class="moz-txt-citetags">> > </span>will be easier to apply them at runtime, but it will be harder to
|
|
<span class="moz-txt-citetags">> > </span>correlate them in UI. Plus, if any of them get modified/removed, it may
|
|
<span class="moz-txt-citetags">> > </span>be non-trivial to troubleshoot the issue.
|
|
<span class="moz-txt-citetags">> > </span>The other approach is to store the forward rules only in one place (the
|
|
<span class="moz-txt-citetags">> > </span>target, 'work' in this example? or the source, 'sys-net' here?). This
|
|
<span class="moz-txt-citetags">> > </span>way, it's harder to mess thing up. But when applying the rules (building
|
|
<span class="moz-txt-citetags">> > </span>rule sets for qubes-firewall service in all the involved VMs), you need
|
|
<span class="moz-txt-citetags">> > </span>to check several places.
|
|
<span class="moz-txt-citetags">> > </span>Plus, the UI should clearly show such redirected ports at all involved
|
|
<span class="moz-txt-citetags">> > </span>places, because it does affect system security - it must be easy to spot
|
|
<span class="moz-txt-citetags">> > </span>if any redirects are enabled.
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>To make things more complex (sorry...), there may be a VPN or other
|
|
<span class="moz-txt-citetags">> > </span>proxy service (Tor?) involved. For example:
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>sys-net -> sys-firewall -> sys-vpn -> work
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>In such a case, the "external" VM for 'work' is not really sys-net, but
|
|
<span class="moz-txt-citetags">> > </span>rather sys-vpn. And actually you need to be careful to not accidentally
|
|
<span class="moz-txt-citetags">> > </span>bypass VPN either by allowing 'work' to communicate outside of the VPN,
|
|
<span class="moz-txt-citetags">> > </span>or (maybe even worse) systems on the LAN (via sys-net) reach inside VPN.
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>This case is not easy to solve, because currently core-admin has no idea
|
|
<span class="moz-txt-citetags">> > </span>whether sys-vpn (or other such VM) do any of such tunnelling. Maybe we
|
|
<span class="moz-txt-citetags">> > </span>need to (finally) introduce some flag to mark such VMs?
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>And another question: what should happen if you change netvm of 'work'.
|
|
<span class="moz-txt-citetags">> > </span>For example switch to something like:
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span> sys-net -> sys-firewall -> (other VMs, but not 'work')
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span> sys-wifi -> work
|
|
<span class="moz-txt-citetags">> > </span>
|
|
<span class="moz-txt-citetags">> > </span>Should the redirection stay active via sys-wifi? I think it should not,
|
|
<span class="moz-txt-citetags">> > </span>at least not automatically (maybe have an option for that?).
|
|
<span class="moz-txt-citetags">> > </span>
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> </span>
|
|
<span class="moz-txt-citetags">> </span>I understand all of your points and consequently it is hard to figure
|
|
<span class="moz-txt-citetags">> </span>out a catch-all solution.
|
|
<span class="moz-txt-citetags">> </span>
|
|
<span class="moz-txt-citetags">> </span>I tried charting the flow of the possible solution.
|
|
<span class="moz-txt-citetags">> </span><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>
|
|
<span class="moz-txt-citetags">> </span>
|
|
<span class="moz-txt-citetags">> </span>As a sum up:
|
|
<span class="moz-txt-citetags">> </span>1) Rules are stored only in <appvm>/firewall.xml
|
|
<span class="moz-txt-citetags">> </span>2) Rules can either be internal or exteranl (ie: they are applied only
|
|
<span class="moz-txt-citetags">> </span>to <firewallvm> or both to <firewallvm> and its <netvm>)
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
|
|
Please note there may be more VMs in between, some examples at:
|
|
<a class="moz-txt-link-freetext" href="https://www.qubes-os.org/doc/firewall/">https://www.qubes-os.org/doc/firewall/</a>
|
|
|
|
So, I think it's better to define it as:
|
|
1. internal: redirect from immediate parent only (VM's 'netvm' property)
|
|
2. external: redirect on the whole chain up to the top (follow 'netvm'
|
|
property until you get a VM with it set to None).
|
|
|
|
My idea of redirect source was to explicitly point where the redirection
|
|
starts, instead of this automatic internal/external. But indeed the
|
|
automatic may be easier to use.
|
|
|
|
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> </span>3) Forwarding rules should be purged if <appvm> changes <firewall>
|
|
<span class="moz-txt-citetags">> </span>(maybe also if <firewallvm> changes <netvm>? But that would be harde to
|
|
<span class="moz-txt-citetags">> </span>detect I guess)
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
|
|
Or maybe it should be configurable? I'd hate to loose the configuration just
|
|
because I temporarily switched to another netvm (and then switched it
|
|
back)...
|
|
|
|
Or, allow both automatic internal/external and explicit redirect source.
|
|
Then, setting redirect type to 'internal' would set the redirect point to
|
|
the VM's direct upstream (and would automatically adjust if you change
|
|
netvm), setting to 'external' would follow the whole chain. But setting
|
|
to explicit sys-net for example would always try to apply rule there, if
|
|
reachable (and add no rules, if not reachable).
|
|
|
|
Does it make sense?
|
|
|
|
Maybe let me explain it on a diagram (see attachment). Especially see
|
|
how redirections to appvm3 has changed after switching it from sys-vpn
|
|
to sys-firewall: the "internal" redirection (in green) remained there,
|
|
but the "sys-vpn" one (in blue) did not.
|
|
|
|
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> </span>4) Users should be able to specify both the forwarded port and
|
|
<span class="moz-txt-citetags">> </span>destination port as you were saying
|
|
<span class="moz-txt-citetags">> </span>5) Users should be able to eventually restrict forwarding to designated
|
|
<span class="moz-txt-citetags">> </span>networks (with 0.0.0.0/0 being the wildcard instead of being a wildcard
|
|
<span class="moz-txt-citetags">> </span>by default)
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
|
|
I wonder if this should be combined in the same rule, or maybe separate
|
|
rule for limiting? But maybe indeed putting it into the same rule may be
|
|
easier (avoids duplicating port numbers etc).
|
|
|
|
</pre><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> </span>However, in this case it will surely be harder to display the rules in
|
|
<span class="moz-txt-citetags">> </span>all the affected vms.
|
|
<span class="moz-txt-citetags">> </span>The other approach, as you were suggesting, of adding each specific rule
|
|
<span class="moz-txt-citetags">> </span>in each vm conf does make sense, but I think then it would necessary
|
|
<span class="moz-txt-citetags">> </span>something to keep track of the rule dependencies (such as a unique
|
|
<span class="moz-txt-citetags">> </span>identifier). Furthermore there is a higher risk of having orphaned rules
|
|
<span class="moz-txt-citetags">> </span>or a inconsistent state.
|
|
<span class="moz-txt-citetags">> </span>
|
|
<span class="moz-txt-citetags">> </span>Furthermore, in the "internal" vpn case that I have in mind, the idea is
|
|
<span class="moz-txt-citetags">> </span>to forward the local port via the VPN interface or Tor (but in the Tor
|
|
<span class="moz-txt-citetags">> </span>case users should just stick to Whonix). Some providers, such as
|
|
<span class="moz-txt-citetags">> </span>Mullvad, AirVPN, PIA etc allows port forwarding this way and I think
|
|
<span class="moz-txt-citetags">> </span>that's the most relevant case since it allows exposing a service on the
|
|
<span class="moz-txt-citetags">> </span>internet while maintaining a bit of privacy/anonimity and whithout
|
|
<span class="moz-txt-citetags">> </span>needing to bypass the local network NAT. Is this the same case you are
|
|
<span class="moz-txt-citetags">> </span>referring to?
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
|
|
Yes, exactly.
|
|
|
|
</pre><blockquote type=cite style="color: #007cff;"><blockquote type=cite style="color: #007cff;"><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> > </span>And finally, don't forget IPv6 exists. Which means you can have the same
|
|
<span class="moz-txt-citetags">> > </span>port on IPv4 and IPv6. And theoretically they could be redirected to
|
|
<span class="moz-txt-citetags">> > </span>different places (but I'm not sure if that's a good idea...).
|
|
<span class="moz-txt-citetags">> > </span>
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
<span class="moz-txt-citetags">> </span>
|
|
<span class="moz-txt-citetags">> </span>I think that once we have figured out the overall logic to implement, it
|
|
<span class="moz-txt-citetags">> </span>should not be hard to duplicate it for ipv4/ipv6. I think the main
|
|
<span class="moz-txt-citetags">> </span>problem to think about is to insert proper checks to prevent users from
|
|
<span class="moz-txt-citetags">> </span>adding mixed rules.
|
|
</pre></blockquote><pre wrap class="moz-quote-pre">
|
|
|
|
Yes, that sounds about right.
|
|
|
|
<div class="moz-txt-sig">--
|
|
Best Regards,
|
|
Marek Marczykowski-Górecki
|
|
Invisible Things Lab
|
|
</div>
|
|
</fieldset>
|
|
</pre></div><BR><DIV CLASS="moz-attached-image-container"><IMG CLASS="moz-attached-image" shrinktofit="yes" SRC="EmbeddedImages/0.jpg"></DIV><br><hr><br><div style="font-size:12px;color:black;"><img src="data:image/gif;base64,R0lGODdhDwAPAOMAAP///zEwYmJlzQAAAPr6+vv7+/7+/vb29pyZ//39/YOBg////////////////////ywAAAAADwAPAAAESRDISUG4lQYr+s5bIEwDUWictA2GdBjhaAGDrKZzjYq3PgUw2co24+VGLYAAAesRLQklxoeiUDUI0qSj6EoH4Iuoq6B0PQJyJQIAOw==">
|
|
<ul><li><a href="Attachments/network-graph.jpg">Attachments/network-graph.jpg</li></a></ul></div><div class='' ></div></body>
|
|
</html> |