12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576 |
- <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>
|