On 2/17/21 7:27 PM, Marek Marczykowski-Górecki wrote: > On Mon, Dec 28, 2020 at 11:50:56AM +0100, Giulio wrote: >> Hello everybody, although I understand it's a bit early, I've got a >> project idea for the 2021 GSoC. I plan to also apply to it as a student >> if it gets reviewed and approved, but that of course will come later. > >> # Qubes GSoC 2021: Simplified external port forwarding and automatic NAT >> traversal >> ## Introduction >> Forwarding ports to Qubes VM is currently possible only though a multi >> step, error prone, manual process that also requires writing custom >> configuration in order to survive between reboots. >> Things as simple as starting a webserver or netcat for lan file sharing >> can be eventually a troublesome and time-wasting process[1][2]. > > 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. > >> Furthermore, applications that rely on NAT traversal protocols such as >> those for audio and video communications do not work in direct P2P mode >> with STUN and always use TURN instead[3]. > >> ## Project goals >> Implement a GUI for automatic and persistent, eventually with a >> predefined timespan (ie: until reboot), port forwarding. The idea is to >> split horizontally the "Firewall Rules" tab in the "Qubes Settings" >> window and add another area below it. Add a checkbox to enable NAT >> traversal requests. When the checkbox is selected, the FirwallVM will >> redirect NAT traversal requests to a local python daemon or a dedicated >> VM that will negotiate the NAT traversal and configure the network >> accordingly. In this case, prompt the user in Dom0 about the NAT >> traversal request. Of course the qvm-* set of tools must e able to >> achieve the same tasks via CLI. > > While indeed appealing, this feature may be very easily abused to > unknowingly expose a VM to an extra attack surface. > At the very least there needs to be a way to a) see that some > connections are redirected into a VM and b) easy way to block them. > But to be honest, I'm not sure if this isn't too dangerous. Allowing a > VM to influence the firewall, even as a proposal for user to confirm > sounds risky.
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. 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 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. Sincerely, Demi Obenour -- 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 qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/60c00695-2dd6-05f0-a246-ed81b5f094ce%40gmail.com.
OpenPGP_signature
Description: OpenPGP digital signature
