On the VPS we use:
- 80 (standard http)
- 443 (standard https)
- 22 (obv for standard ssh)
- 9090 (metrics / internal so I can have an idea of the generic usage like reqs/s and active connections)
Client-Side: The -R 80:localhost:8080 Explained
The 80 in -R 80:localhost:8080 is not a real port on the server. It's a virtual bind port that tells the SSH client what port to "pretend" it's listening on.
No port conflicts - The server doesn't actually bind to port 80 per tunnel. Each tunnel gets an internal listener on 127.0.0.1:random (ephemeral port). The 80 is just metadata passed in the SSH forwarded-tcpip channel. All public traffic comes through single port 443 (HTTPS), routed by subdomain.
So What Ports Are "Available" to Users?
Any port - because it doesn't matter! Users can specify any port in -R:
ssh -t -R 80:localhost:3000 proxy.tunnl.gg # Works
ssh -t -R 8080:localhost:3000 proxy.tunnl.gg # Also works
ssh -t -R 3000:localhost:3000 proxy.tunnl.gg # Also works
ssh -t -R 1:localhost:3000 proxy.tunnl.gg # Even this works!
The number is just passed to the SSH client so it knows which forwarded-tcpip requests to accept. The actual routing is done by subdomain, not port.
Why Use 80 Convention?
It's just convention - many SSH clients expect port 80 for HTTP forwarding. But functionally, any number works because:
- Server extracts BindPort from the SSH request
- Stores it in the tunnel struct
- Sends it back in forwarded-tcpip channel payload
- Client matches on this to forward to correct local port
- The "magic" is that all 1000 possible tunnels share the same public ports (22, 80, 443) and are differentiated by subdomain.
Yeah, this is the next step. I first wanted to understand if this gets any traction. I think I will provide a dockerized version for the server part that you can just run with a simple command and maybe some interface to create api keys and distribute them to your users.
Fair enough from a business standpoint, but seeing as there are massive privacy/security risks involved in exposing your data to an opaque service, the open source component is probably a non-optional aspect of the value prop.
As someone who has launched something free on HN before, the resulting signups were around 1/3rd valid users doing cool things and checking things out, and 2/3rds nefarious users.
My service (which doesn't have public access, only via SSH as a client) was used by a ransomware gang, which involved the service in investigation from Dutch CERT and Dubai police.
I run playit.gg. Abuse is a big problem on our free tier. I’d get https://github.com/projectdiscovery/nuclei setup to scan your online endpoints and autoban detections of c2 servers.
Thanks for sharing this. I run packetriot.com, another tunneling service and I ended up writing my own scanner for endpoints using keyword lists I gathered from various infosec resources.
I had done some account filtering for origins coming out of Tor, VPN networks, data centers, etc. but I recently dropped those and added an portal page for free accounts, similar to what ngrok does.
It was very effective at preventing abuse. I also added mechanism for reporting abuse on the safety page that's presented.
Our services were used for C2 as well. I investigated it a bit but eventually decided to just drop TCP forwarding from our free-tier and that reduced our abuse/malware reports for C2 over TCP to zero essentially.
One path I looked at was to use the VirusTotal API to help identify C2's that other security organizations were identifying and leverage that to automatically take down malicious TCP endpoints. I wrote some POCs but did not deploy them. It's something I plan on taking up again at some point next year.
Want to chat on discord? Maybe we could combine efforts to try and stop people abusing our services :). We have a few vendors sending us automated reports, maybe I could open it up for multiple projects.
Do you have funding to cover the paying the bandwidth costs which will ultimately result from this? Or if you're running this from a home network, does anyone know if OP should be concerned of running into issues with their ISP?
The tunnel host appears to be a Hetzner server, they are pretty generous with bandwidth but the interesting thing I learned about doing some scalability improvements at a similar company [0] is that for these proxy systems, each direction’s traffic is egress bandwidth. Good luck OP, the tool looks cool. Kinda like pinggy.
Hey, I didn't mean to sell another tool over yours! It's just an experience that popped into my mind and I wanted to share. I appreciate your work and contributing to the problem space of exposing a local service. Thank you.
