3 ms·

Except its not. Port forwarding exposes your local environment to the internet, unrestricted. Pinggy (and other sharing platforms - https://github.com/anderspit

by PLG88 2y ago

Except its not. Port forwarding exposes your local environment to the internet, unrestricted. Pinggy (and other sharing platforms - https://github.com/anderspitman/awesome-tunneling https://github.com/anderspitman/awesome-tunneling) share a resource on a public IP, which should be at the very least behind basic auth. The 'better alternative' you describe is an overlay network. These things have different purposes.

resoluteteeth 2y ago
OK, looking into it more it appears that pinggy actually has pretty good options for adding authentication (I guess that's what you were referring to by basic authentication, not just the service being exposed having basic authentication) and based on that it does seem that it could be more secure than just forwarding the port if the service being exposed doesn't have built in authentication, and that would make me a lot more tempted to use it. The article for some reason didn't explain that at all or show examples using pinggy's authentication features. If the article had talked about that, the assertion about being more secure would have made a lot more sense.
- PLG88 2y ago
  Agreed. It surprises me that many of these services do not either lead with auth or have it as an important secondary. For many, port forwarding is a pain, so it solves that, but the security IMHO is just as important. It's a shame lists like - https://github.com/anderspitman/awesome-tunneling https://github.com/anderspitman/awesome-tunneling - do not call this out. fwiw, the one I work on, zrok.io (in truth, I work on its parent project, OpenZiti) has that hardening and auth because we believe its vital.
rmbyrro 2y ago
The question is: how long until a vulnerability in your - now public - resource behind Pinggy is discovered and exploited? The vuln is there, trust me. If you use Wireguard or Tailscale, your network is private. Only other devices in this private network could explore this vuln.
- PLG88 2y ago
  We dont disagree. As I stated, "These things have different purposes". If you want to publicly share a resource, use a tool which provides that in the knowledge that if there is a vulnerability, it could be exploited. Using an overlay network reduces the risk further, but it means the end user needs to have an endpoint (unless you have an overlay with a 'clientless endpoint', but that's another topic). For some use cases, the endpoint is infeasible.

by PLG88 2y ago

resoluteteeth 2y ago

OK, looking into it more it appears that pinggy actually has pretty good options for adding authentication (I guess that's what you were referring to by basic authentication, not just the service being exposed having basic authentication) and based on that it does seem that it could be more secure than just forwarding the port if the service being exposed doesn't have built in authentication, and that would make me a lot more tempted to use it. The article for some reason didn't explain that at all or show examples using pinggy's authentication features. If the article had talked about that, the assertion about being more secure would have made a lot more sense.

PLG88 2y ago
Agreed. It surprises me that many of these services do not either lead with auth or have it as an important secondary. For many, port forwarding is a pain, so it solves that, but the security IMHO is just as important. It's a shame lists like - https://github.com/anderspitman/awesome-tunneling https://github.com/anderspitman/awesome-tunneling - do not call this out. fwiw, the one I work on, zrok.io (in truth, I work on its parent project, OpenZiti) has that hardening and auth because we believe its vital.

rmbyrro 2y ago

The question is: how long until a vulnerability in your - now public - resource behind Pinggy is discovered and exploited? The vuln is there, trust me. If you use Wireguard or Tailscale, your network is private. Only other devices in this private network could explore this vuln.

PLG88 2y ago
We dont disagree. As I stated, "These things have different purposes". If you want to publicly share a resource, use a tool which provides that in the knowledge that if there is a vulnerability, it could be exploited. Using an overlay network reduces the risk further, but it means the end user needs to have an endpoint (unless you have an overlay with a 'clientless endpoint', but that's another topic). For some use cases, the endpoint is infeasible.