Re: [qubes-devel] [GSoC 2021] Project idea: Simplified external port forwarding and automatic NAT traversal
-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,
Re: [qubes-devel] [GSoC 2021] Project idea: Simplified external port forwarding and automatic NAT traversal
On Sat, Mar 20, 2021 at 10:44:10AM +0100, Giulio wrote: Hi, does anyone have time to mentor or further discuss this proposal? I don't have any special expertise, but I would love to see it implemented! -- 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/YFZHvK/ia9YBJ5z9%40danwin1210.me.
Re: [qubes-devel] [GSoC 2021] Project idea: Simplified external port forwarding and automatic NAT traversal
Hi, does anyone have time to mentor or further discuss this proposal? Thanks Giulio 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 qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ce9989fe-72c4-5769-2005-7296e6f58355%40anche.no.
Re: [qubes-devel] [GSoC 2021] Project idea: Simplified external port forwarding and automatic NAT traversal
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 qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/d063dedc-285c-9e2b-74dd-c7a7656243ff%40anche.no.
Re: [qubes-devel] [GSoC 2021] Project idea: Simplified external port forwarding and automatic NAT traversal
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,
Re: [qubes-devel] [GSoC 2021] Project idea: Simplified external port forwarding and automatic NAT traversal
I deeply thought that the very best idea that was ever proposed was network server project by @Rudd-o. In its actual state, it lacks cascading to upstream AppVMs, but that implementation on 3.2 was actually permitting the Qubesos firewall GUI to define IN ports, having a visual way of seeing what is happening there. On February 18, 2021 12:27:33 AM UTC, "Marek Marczykowski-Górecki" wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA256 > >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. > >> ## Implementation >> Implementation will be discussed after the project idea is reviewed. >> >> ## Timeline >> Too early to plan, discuss implementation first. >> >> ## About me >> I'm a early adopter and long time QubesOS user. I've been using QubesOS >> ad my main operating systems for 5 years now. Although I've never >> contributed (yet) to the QubesOS source code, I've sometimes written >> about it[4]. >> Port forwarding is an issue that often arises in my daily usage, both >> for file sharing, tests, and in the field of security for serving >> payloads or receiving reverse shells. >> I will be graduating in March and I'm currently applying for some >> masters that will all eventually start on Semptember 2021. This will >> leave me with plenty of time for both working on the idea and then >> complete the task. >> I've already worked both privately and with my University with >> deadlines. I've a broad experience in python and in debugging problems >> in Qubes. >> In the past I've both done some security research and some personal >> projects, most of them can be found at [5]. >> >> [1] - https://github.com/QubesOS/qubes-issues/issues/3556 >> [2] - >> https://www.reddit.com/r/Qubes/comments/8cb57i/how_to_achieve_qube_to_qube_communication_port/ >> [3] - https://github.com/QubesOS/qubes-issues/issues/6225 >> [4] - https://git.lsd.cat/g/thinkpad-coreboot-qubes >> [5] - https://lsd.cat >> > >- -- >Best Regards, >Marek Marczykowski-Górecki >Invisible Things Lab >-BEGIN PGP SIGNATURE- > >iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmAttHQACgkQ24/THMrX >1yxAGwf/dLzur1FJApE4luGdOy9w4t9UWFas8yMNVZcE55iGo5j7fUz9zE5v2oYd >74GLec2npIrTQeF0YyLtFM7Qq37783tTPEcK0N0F4mFFackvyFf/5tYYK6tFTYBT >MMF4HhuNDRWcM6HOk2MObdro034gqo8hoELTUIWWN5/TVCksg1OJpQs3t+PflbEq >RIlgCpxBobQHfM47wuP1dkGE7DLFrm5fLUustYMNK0Upt/A+KKR2lGTRwtWD8CwX >sUffOJJswUSN8WCuteuD3DoqijEKO/B9YY8BGrJoPKFau9q775ywQqaTTfTgVKxG >Lr1Tm3huP0EaBS8Qdu8RUId7K0NEtw== >=1YVo >-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 qubes-devel+unsubscr...@googlegroups.com. >To view this discussion on the web visit
Re: [qubes-devel] [GSoC 2021] Project idea: Simplified external port forwarding and automatic NAT traversal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. > ## Implementation > Implementation will be discussed after the project idea is reviewed. > > ## Timeline > Too early to plan, discuss implementation first. > > ## About me > I'm a early adopter and long time QubesOS user. I've been using QubesOS > ad my main operating systems for 5 years now. Although I've never > contributed (yet) to the QubesOS source code, I've sometimes written > about it[4]. > Port forwarding is an issue that often arises in my daily usage, both > for file sharing, tests, and in the field of security for serving > payloads or receiving reverse shells. > I will be graduating in March and I'm currently applying for some > masters that will all eventually start on Semptember 2021. This will > leave me with plenty of time for both working on the idea and then > complete the task. > I've already worked both privately and with my University with > deadlines. I've a broad experience in python and in debugging problems > in Qubes. > In the past I've both done some security research and some personal > projects, most of them can be found at [5]. > > [1] - https://github.com/QubesOS/qubes-issues/issues/3556 > [2] - > https://www.reddit.com/r/Qubes/comments/8cb57i/how_to_achieve_qube_to_qube_communication_port/ > [3] - https://github.com/QubesOS/qubes-issues/issues/6225 > [4] - https://git.lsd.cat/g/thinkpad-coreboot-qubes > [5] - https://lsd.cat > - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmAttHQACgkQ24/THMrX 1yxAGwf/dLzur1FJApE4luGdOy9w4t9UWFas8yMNVZcE55iGo5j7fUz9zE5v2oYd 74GLec2npIrTQeF0YyLtFM7Qq37783tTPEcK0N0F4mFFackvyFf/5tYYK6tFTYBT MMF4HhuNDRWcM6HOk2MObdro034gqo8hoELTUIWWN5/TVCksg1OJpQs3t+PflbEq RIlgCpxBobQHfM47wuP1dkGE7DLFrm5fLUustYMNK0Upt/A+KKR2lGTRwtWD8CwX sUffOJJswUSN8WCuteuD3DoqijEKO/B9YY8BGrJoPKFau9q775ywQqaTTfTgVKxG Lr1Tm3huP0EaBS8Qdu8RUId7K0NEtw== =1YVo -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 qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YC20dXK%2BxXKUUx7n%40mail-itl.
[qubes-devel] [GSoC 2021] Project idea: Simplified external port forwarding and automatic NAT traversal
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]. 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. ## Implementation Implementation will be discussed after the project idea is reviewed. ## Timeline Too early to plan, discuss implementation first. ## About me I'm a early adopter and long time QubesOS user. I've been using QubesOS ad my main operating systems for 5 years now. Although I've never contributed (yet) to the QubesOS source code, I've sometimes written about it[4]. Port forwarding is an issue that often arises in my daily usage, both for file sharing, tests, and in the field of security for serving payloads or receiving reverse shells. I will be graduating in March and I'm currently applying for some masters that will all eventually start on Semptember 2021. This will leave me with plenty of time for both working on the idea and then complete the task. I've already worked both privately and with my University with deadlines. I've a broad experience in python and in debugging problems in Qubes. In the past I've both done some security research and some personal projects, most of them can be found at [5]. [1] - https://github.com/QubesOS/qubes-issues/issues/3556 [2] - https://www.reddit.com/r/Qubes/comments/8cb57i/how_to_achieve_qube_to_qube_communication_port/ [3] - https://github.com/QubesOS/qubes-issues/issues/6225 [4] - https://git.lsd.cat/g/thinkpad-coreboot-qubes [5] - https://lsd.cat -- 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/34100fb0-60e7-21f8-8130-998529772785%40anche.no.