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