[GSoC 2021] Project idea: Simplified external port forwarding and automatic NAT traversal
75 views
Skip to first unread message
Giulio
Dec 28, 2020, 5:51:01 AM12/28/20
to qubes...@googlegroups.com
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
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
Marek Marczykowski-Górecki
Feb 17, 2021, 7:27:38 PM2/17/21
to Giulio, qubes...@googlegroups.com
-----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.
- --
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-----
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].
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.
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.
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-----
Insurgo Technologies Libres / Open Technologies
Feb 17, 2021, 7:43:26 PM2/17/21
to qubes...@googlegroups.com, Marek Marczykowski-Górecki, Giulio
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.
>--
>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...@googlegroups.com.
>To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YC20dXK%2BxXKUUx7n%40mail-itl.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
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.
>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...@googlegroups.com.
>To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YC20dXK%2BxXKUUx7n%40mail-itl.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Demi M. Obenour
Feb 20, 2021, 3:28:09 PM2/20/21
to qubes...@googlegroups.com
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
Giulio
Mar 1, 2021, 9:16:31 AM3/1/21
to qubes...@googlegroups.com
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.
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
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.
>>
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.
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
could be approved, I can look into STUN well and propose the development
more in details!
>
> Sincerely,
>
> Demi Obenour
>
>
Giulio
Giulio
Mar 20, 2021, 5:44:18 AM3/20/21
to qubes...@googlegroups.com
Hi,
does anyone have time to mentor or further discuss this proposal?
Thanks
Giulio
does anyone have time to mentor or further discuss this proposal?
Thanks
Giulio
tetra...@danwin1210.me
Mar 23, 2021, 6:02:07 AM3/23/21
to Giulio, qubes...@googlegroups.com
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
>Hi,
>does anyone have time to mentor or further discuss this proposal?
implemented!
Marek Marczykowski-Górecki
Mar 23, 2021, 5:41:34 PM3/23/21
to Giulio, qubes...@googlegroups.com, Frédéric Pierret
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
> does anyone have time to mentor or further discuss this proposal?
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.
> --
> 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...@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.
> 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...@googlegroups.com.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
1yy1iAf/XhlylrXaLaZCnrbdCh0ovd6rZsacG7PKM2xVZGnz3Ye+r9hjuPxXf3Hz
oOR07eH+MaKNkodUS6JAtouW9OtPYRRbYQQcb/4GgpDjWrgIFiJ5mgh9kniWPlMm
Id5lF7DsC+vxmGBIXYBlLRcSijnnBtEcUa0aYWDLWT37gW9NpjxNSb9EwqH0Iriv
Uqb13MV6soPSNq008lFZLT2NC7JtdJC549/U/okUH0cEZGisN09l7ij1jKeDyEFx
qrzSkmFupvbquruyVQaL6YlKo4rt9rVSPAE90/BvBUP1PG2aZ/hg8qs7yGprf1z/
efaPW0emyguOjHqVFmTrIq6BpA3a6Q==
=7yUh
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages