76 lines
4.2 KiB
HTML
76 lines
4.2 KiB
HTML
|
<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 <frederic.pierret@qubes-os.org>, Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com></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> <-> sys-net (10.137.0.5) <-> sys-firewall (10.137.0.6)
|
||
|
|
<-> sys-vpn (10.137.0.13) <-> sys-tor (10.137.0.14) <-> 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>
|