gsoc/mails/20210717-Re_GSoC Port Forwarding-1086.html

76 lines
4.2 KiB
HTML
Raw Normal View History

2021-10-19 18:22:56 +02:00
<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>17/07/2021, 17:31</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>Frédéric Pierret &lt;frederic.pierret@qubes-os.org&gt;, Marek Marczykowski-Górecki &lt;marmarek@invisiblethingslab.com&gt;</td></tr></table><br>
<div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode">Hi,
<br>thank you for the positive feedback, I really appreciate it.
<br>I spent the past couple of days digging into the "rules distribution"
mechanism in the various QubesDB. It really took some time to find a
better way to handle and separate the rules for each domain at every
'step' of their network path.
<br>
<br><a class="moz-txt-link-freetext" href="https://github.com/lsd-cat/qubes-core-admin/commit/0cf04fb290469340a59a013531bba6e06e8a0169">https://github.com/lsd-cat/qubes-core-admin/commit/0cf04fb290469340a59a013531bba6e06e8a0169</a>
<br>
<br>The idea here is that each appvm will have a separate QubesDB folder on
the untrusted qdb of each netvm. This is for easier cleaning and
reloading, and can be used in the future when displaying the forwarding
chain at each step like we were discussing with Marek in the first
emails. A practical example follows.
<br>
<br>Assume the following network path:
<br>
<br><b class="moz-txt-star"><span class="moz-txt-tag">*</span>internet/lan<span class="moz-txt-tag">*</span></b> &lt;-&gt; sys-net (10.137.0.5) &lt;-&gt; sys-firewall (10.137.0.6)
&lt;-&gt; sys-vpn (10.137.0.13) &lt;-&gt; sys-tor (10.137.0.14) &lt;-&gt; personal
(10.137.0.10)
<br>
<br>And the following rule:
<br># qvm-firewall personal add action=forward forwardtype=external
proto=tcp srcports=443-443 dstports=8443-8443 srchost=192.168.0.1/24
<br>
<br>Here are the QubesDB entries that are automatically added, to be
consumed from the core-agent-linux:
<br>
<br>In sys-net:
<br>key = /qubes-firewall-forward/personal/10.137.0.6/0000
<br>value = action=forward forwardtype=external proto=tcp srcports=443-443
dstports=8443-8443 srchost=192.168.0.1/24
<br>
<br>In sys-firewall:
<br>key = /qubes-firewall-forward/personal/10.137.0.13/0000
<br>value = action=forward forwardtype=external proto=tcp srcports=443-443
dstports=8443-8443 srchost=192.168.0.1/24
<br>
<br>In sys-vpn:
<br>key = /qubes-firewall-forward/personal/10.137.0.14/0000
<br>value = action=forward forwardtype=external proto=tcp srcports=443-443
dstports=8443-8443 srchost=192.168.0.1/24
<br>
<br>In sys-tor:
<br>key = /qubes-firewall-forward/personal/10.137.0.10/0000
<br>value = action=forward forwardtype=external proto=tcp srcports=443-443
dstports=8443-8443 srchost=192.168.0.1/24
<br>
<br>Although this mechanism seems complex, I was not able to think of a
simpler solution. Furthermore I think it is important to know which
appvm is requesting the forwarding at every step, both for debugging and
auditing purposes. Lastly, the next hop ip address has to be determined
automatically anyway and writtem somewhere so there it is.
<br>
<br>I am also thinking about adding a couple of flags to let the nodes know
which one is the first and which one is the last since especially the
last needs additional rules for the external forwarding.
<br>
<br>One more thing, maybe between internal hops it makes sense to randomize
the forwarded ports? This way we can prevent forwarding from different
appvm which shares the same network path or even just one hop from
overlapping, at least internally. Does it makes sense for you?
<br>
<br>Cheers
<br>Giulio
<br></div></body>
</html>
</table></div>