-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, Mar 20, 2021 at 10:44:10AM +0100, Giulio wrote: > Hi, > does anyone have time to mentor or further discuss this proposal?
Generally, I think easy port forwarding and/or NAT traversal (and maybe also inter-qube connections too?) would be a good GSoC project. And indeed the current "easy" solution is TCP only, which has its limits. I do have concerns expressed in my previous email about this being a potential footgun, but I think this can be solved with appropriate UI (clearly showing if/when a qube has some ports forwarded) and also by having strict opt-in options for that. If you wish to pursue this project, I'll be happy to mentor it, perhaps with someone as a co-mentor (Frédéric?). PS please don't top-post. > On 3/1/21 3:16 PM, Giulio wrote: > > Hello, > > thanks everyone for the comments and inputs. > > > > > >> On 2/17/21 7:27 PM, Marek Marczykowski-Górecki wrote: > >>> > >>> Since some time there is an easier way: > >>> https://www.qubes-os.org/doc/firewall/#opening-a-single-tcp-port-to-other-network-isolated-qube > >>> > >>> It isn't fully automatic, but _much_ easier than manual iptables rules. > >>> > > > > This is surely an improvement over the manual iptables rules. However > > it's TCP only, and thus, for example for torrent or other media > > applications it is not sufficient. Furthermore, if I get it correcly, if > > the number or qubes and forwarded ports involved grows, it would be hard > > to keep track of the network flows. > > > >> On 2/20/21 9:28 PM, Demi M. Obenour wrote: > >> I have mixed feelings about this. > >> > >> On the one hand, this is indeed risky. On the other hand, P2P > >> applications are currently crippled except in sys-net. Some protocols > >> can fall back to TURN servers, but that doesn’t always work and is > >> at best a fallback behavior. I have personally hit this problem more > >> than once. NAT traversal and port forwarding aren’t something > >> everyone needs, but for those who *do* need it, it is extremely > >> difficult to work around the lack of it. > > > > It is indeed an 'hard' issue for those using Qubes at the workplace. In > > the context of a penetration tester, this is especially limiting, > > because as it is now, it introduces a lot of additional work that can be > > a huge issue in time constrained engagements. Being able to forward > > ports faster than it is now would help both for fast file sharing with > > colleagues, payload hosting, reverse shell listeners and much more. > > Furthermore, since port forwarding is used a lot, an overall view to see > > the port forwarding status would help keep tracks of potential holes > > introduced. > > > >> > >> IMO, port forwarding and NAT traversal should be clearly separated, > >> as the use-cases are extremely different. Port forwarding is used > >> to expose a server to the outside world, whereas NAT traversal is > >> used for P2P communication. Furthermore, my understanding is that > >> port forwarding usually needs to be persistent, whereas NAT traversal > >> usually does not. And port forwarding often requires a specific port > >> to be forwarded, whereas for NAT traversal I would not be surprised > >> if the system can choose the port > > I totally agree that separation would be a good idea. > > > >> > >> I agree that allowing a qube to set up its own port forwarding is a > >> Bad Idea in most cases. That said, it should be possible to set up > >> port forwarding via the Admin API, with fine-grained access controls. > >> So it should be possible to express, “Qube X can request port Y > >> to be forwarded to it,” as a qrexec policy. In practice, however, > >> I expect most users to manage port forwarding from the management qube. > >> > >> NAT traversal is a different matter altogether. It is already > >> possible for a qube and a peer that are *trying* to establish a P2P > >> connection to do so, by means of a brute force attack. Nobody does > >> this in practice, because it requires (on average) somewhere around > >> 65536 outgoing connections from each side, which is a good way to > >> overload firewalls. But it can be done, assuming that all outgoing > >> UDP traffic is allowed. And there are a large number of applications > >> that need it. These applications often need to set up and tear down > >> connections at will. > >> > >> Overall, I consider allowing qubes to request NAT traversal a net win, > >> provided a few restrictions are enforced: > >> > >> - Only UDP forwarding may be requested. TCP is not allowed. > >> > >> - Only certain ports can be forwarded. Well-known ports (anything > >> in /etc/services) and ports below 1024 are blocked. Ideally, > >> the port number should be chosen by QubesOS, rather than by the > >> requesting qube. > >> > >> - Only the qube that made the request can receive the traffic. > >> Intermediate qubes, such as sys-net and sys-firewall, pass through > >> the traffic, but attempts to listen on the relevant port fail with > >> EADDRINUSE or similar. > >> > >> - NAT traversal is only allowed if a certain preference has been set > >> via the Admin API. > > > > That sounds totally doable for me, but if you feel like the project idea > > could be approved, I can look into STUN well and propose the development > > more in details! > > > >> > >> Sincerely, > >> > >> Demi Obenour > >> > >> > > > > Giulio > > > > -- > You received this message because you are subscribed to the Google Groups > "qubes-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-devel/ce9989fe-72c4-5769-2005-7296e6f58355%40anche.no. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmBaYIQACgkQ24/THMrX 1yy1iAf/XhlylrXaLaZCnrbdCh0ovd6rZsacG7PKM2xVZGnz3Ye+r9hjuPxXf3Hz oOR07eH+MaKNkodUS6JAtouW9OtPYRRbYQQcb/4GgpDjWrgIFiJ5mgh9kniWPlMm Id5lF7DsC+vxmGBIXYBlLRcSijnnBtEcUa0aYWDLWT37gW9NpjxNSb9EwqH0Iriv Uqb13MV6soPSNq008lFZLT2NC7JtdJC549/U/okUH0cEZGisN09l7ij1jKeDyEFx qrzSkmFupvbquruyVQaL6YlKo4rt9rVSPAE90/BvBUP1PG2aZ/hg8qs7yGprf1z/ efaPW0emyguOjHqVFmTrIq6BpA3a6Q== =7yUh -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YFpghE6RWLmdNTuY%40mail-itl.
