20210717-Re_GSoC Port Forwarding-1086.html 4.2 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576
  1. <html>
  2. <head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  3. <title>Re: GSoC Port Forwarding</title>
  4. <link rel="important stylesheet" href="">
  5. <style>div.headerdisplayname {font-weight:bold;}
  6. </style></head>
  7. <body>
  8. <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>
  9. <div class="moz-text-flowed" style="font-family: -moz-fixed; font-size: 14px;" lang="x-unicode">Hi,
  10. <br>thank you for the positive feedback, I really appreciate it.
  11. <br>I spent the past couple of days digging into the "rules distribution"
  12. mechanism in the various QubesDB. It really took some time to find a
  13. better way to handle and separate the rules for each domain at every
  14. 'step' of their network path.
  15. <br>
  16. <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>
  17. <br>
  18. <br>The idea here is that each appvm will have a separate QubesDB folder on
  19. the untrusted qdb of each netvm. This is for easier cleaning and
  20. reloading, and can be used in the future when displaying the forwarding
  21. chain at each step like we were discussing with Marek in the first
  22. emails. A practical example follows.
  23. <br>
  24. <br>Assume the following network path:
  25. <br>
  26. <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)
  27. &lt;-&gt; sys-vpn (10.137.0.13) &lt;-&gt; sys-tor (10.137.0.14) &lt;-&gt; personal
  28. (10.137.0.10)
  29. <br>
  30. <br>And the following rule:
  31. <br># qvm-firewall personal add action=forward forwardtype=external
  32. proto=tcp srcports=443-443 dstports=8443-8443 srchost=192.168.0.1/24
  33. <br>
  34. <br>Here are the QubesDB entries that are automatically added, to be
  35. consumed from the core-agent-linux:
  36. <br>
  37. <br>In sys-net:
  38. <br>key = /qubes-firewall-forward/personal/10.137.0.6/0000
  39. <br>value = action=forward forwardtype=external proto=tcp srcports=443-443
  40. dstports=8443-8443 srchost=192.168.0.1/24
  41. <br>
  42. <br>In sys-firewall:
  43. <br>key = /qubes-firewall-forward/personal/10.137.0.13/0000
  44. <br>value = action=forward forwardtype=external proto=tcp srcports=443-443
  45. dstports=8443-8443 srchost=192.168.0.1/24
  46. <br>
  47. <br>In sys-vpn:
  48. <br>key = /qubes-firewall-forward/personal/10.137.0.14/0000
  49. <br>value = action=forward forwardtype=external proto=tcp srcports=443-443
  50. dstports=8443-8443 srchost=192.168.0.1/24
  51. <br>
  52. <br>In sys-tor:
  53. <br>key = /qubes-firewall-forward/personal/10.137.0.10/0000
  54. <br>value = action=forward forwardtype=external proto=tcp srcports=443-443
  55. dstports=8443-8443 srchost=192.168.0.1/24
  56. <br>
  57. <br>Although this mechanism seems complex, I was not able to think of a
  58. simpler solution. Furthermore I think it is important to know which
  59. appvm is requesting the forwarding at every step, both for debugging and
  60. auditing purposes. Lastly, the next hop ip address has to be determined
  61. automatically anyway and writtem somewhere so there it is.
  62. <br>
  63. <br>I am also thinking about adding a couple of flags to let the nodes know
  64. which one is the first and which one is the last since especially the
  65. last needs additional rules for the external forwarding.
  66. <br>
  67. <br>One more thing, maybe between internal hops it makes sense to randomize
  68. the forwarded ports? This way we can prevent forwarding from different
  69. appvm which shares the same network path or even just one hop from
  70. overlapping, at least internally. Does it makes sense for you?
  71. <br>
  72. <br>Cheers
  73. <br>Giulio
  74. <br></div></body>
  75. </html>
  76. </table></div>