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/d063dedc-285c-9e2b-74dd-c7a7656243ff%40anche.no.
