Exposing a web service with Cloudflare Tunnel (2022) | Hacker News Reader

Exposing a web service with Cloudflare Tunnel (2022)

erisa.dev

110 pointssturza44 comments

I'm sorry, I don't get the point. Perhaps I'm missing something.

If I open a single port to my home server, then anybody can send any traffic to my server on that port. The attack surface is exactly the process running on my home server, listening on that port.

If I use the cloudflare tunnel, anybody using my web service connects to some cloudflare server which transparantly forwards, through the tunnel, everything to the process running at home. The attack surface is ... exactly the process running on my home server, receiving everything coming into the tunnel, effectively listening on the port opened on the cloudflare server.

Where is the difference? Any security issue in the process running on my server that can be exploited by sending traffic to it is attackable in either case.

Does cloudflare filter the traffic in any way? How does it know what's good and what's bad traffic?

I was personally using tailscale funnel (similar?) because my isp didn’t give me a static ip moreso than for any security reason.

Yeah the point of CloudFlare tunel is absolutely not what is shown in this article. It's to privately expose services on the web without opening ports.

You can out auth, georestrictions, etc. so that people are authorized before they ever reach your computer.

I expose a lot of services on my NAS via CloudFlare tunels, but every single one of them is behind an authentication screen managed by CloudFlare and running on their servers.

> If I open a single port to my home server, then anybody can send any traffic to my server on that port. The attack surface is exactly the process running on my home server, listening on that port.

If you open a single port on your home server, you're exposing that port, sure. But you're also exposing your IP, and with that comes attacks on your IP stack, if you're worried about that. Presumably cloudflare proxies application traffic, but likely normalizes fragmentation and tcp flags and what nots.

Additionally, when you're exposing your IP, you're subject to volumetric attacks on your IP. High volume DDoS is often spoofs your IP to UDP servers that will respond, generating high volumes of traffic that overwhelm either your system in general, or the bandwidth on your connection. If you're behind a tunnel, the tunnel endpoint will get that traffic, and Cloudflare seems to manage that well. If you manage to attract a DDoS at your application level, that could very well make it through the tunnel and overwhelm your service. I think Cloudflare does offer some filters for that, but my knowledge is limited. IMHO, most of the value is from avoiding non-application traffic; but I just host most of my stuff in cheap hosting and if someone wants to DDoS me, my server will go down and that's fine.

Sure, DDoS protection sounds useful, but that's not at all what the article is about.

The article is mostly about the how, and not the why. It briefly mentions the why with:

> you might be worried about forwarding your IP and connections to the world without properly securing them. Setting it all up sounds like a hassle, right?

If I were to do this, it would be because I didn't want expose my IP to the world. And the two big reasons not to expose your IP are so you can't be DDoSed, and to reduce the privacy impact. Other people have chimed in that they do it because their IP is not static, and I think you can run the CF tunnel client behind CGNAT, which is also valuable.

Cf also allows adding authentication. Everything from OTP to third party OIDC. Including major providers like google , github etc. In edition blocking access by region or country.

Also not everyone can simply open a port on their router. Lot of people have ISPs that prohibit that or are behind CGNAT. So CF tunnels makes it lot easier for them to selfhost and expose those apps.

> I'm sorry, I don't get the point.

The point is the problem of exposing a port, as opposed to the additional problem of whatever security concerns you imagine your backend "process" may have.

I suppose you may not imagine that exposing a port is somehow problematic. However, it is. First, an open port reveals many things[1] about your operation you would likely prefer not to reveal. Second, it requires Internet service that permits control over open ports, and the authority to utilize it, either or both of which may not be available to you.

I have no trouble appreciating the value of this, both for personal and commercial purposes. The inherent DDOS protection alone is a huge benefit.

[1] Off the top of my head: a.) The ASN and, ultimately, the ISP you're using. b.) The approximate physical location of your system. c.) Through fingerprinting, your firewall device, and whatever problems it has.

Endpoints visible to the internet is one of the main reasons I created connet [1] - with it you can choose when and where to realize the other end. Another benefit is that endpoints talk to each other directly (under many conditions) without traffic ever hitting the cloud.

[1] https://github.com/connet-dev/connet

I might be wrong but I think with Cloudflare tunnel (same with tailscale), you don't need to open that port to the public? That is at least my understanding. Still, Cloudflare must communicate somehow with the external world and if that is compromised, then so is your service too.

I absoltuley love it. Recently used this to host my blog along with multiple hobby projects on my 5-6 years old Raspberry Pi, more on it here:

https://aazar.me/posts/reincarnating-a-raspberry-pi

This is awesome, makes me want to try out a Pi for this.

Would 100% recommend, cheapest bare metal you can get, AFAIK.

Likely, minus those great little used units.

I use CF tunnels all the time at work and for my side projects but I've always found the web ui for remotely managed tunnels a bit hard to use. I recently asked Claude to help me build a TUI so I can easily create and manage them:

https://github.com/justingosan/tunnelman

Just yesterday I added support for adding a traefik reverse proxy that has (just) basic auth (for now) for a little bit of added protection

The missing part of this recipe is to make it so that when your internet exposed app gets compromised the attacker doesn’t have easy access to your home network.

I greatly appreciate the fact that solutions to the real concern you point out are not somehow bundled into this. There are many ways to deal with isolating the backend, and I prefer my own, and evolving them as and when I wish. Cloudflare Tunnel is a primitive that solves the part I can't without much greater effort and expense.

AFAIKT it violates CF ToS if you host a service that streams media traffic via Cloudflare Tunnel.

I was worried about this and had to expose my Plex on the internet protected by oauth2-proxy.

Does violating ToS change your decision making?

Being banned from Cloudflare would break my personal email (they’re the registrar) and portfolio site.

So, yes.

Maybe it would be different if you were exclusively using it as a tunnel service.

I've been using this for years. There's even a kubernetes deployment to directly point your tunnel to your local kubetnetes network. Cloudflare's free tier is very generous. I've never experienced any issues with this solution.

Do they have an operator to create the ingress rules and what not? I’m running their tunnel docker container but I still have to do some clicking around in the UI

I'm not aware of one. You do raise a good point, there still is some things to configure in the UI. My understanding is this can all be automated by API, but I haven't seen a full k8s automation yet. I'll post here if I find anything

I do this for my services at home, and added Zero Trust auth for some services. Also created a Python script that adds my compose containers automatically fo cloudflare/Zero Trust based on annotations.

The big - really big - downside for me is the CF termsofservice which suggest that any data pushed through their service is perpetually licensed to them:

> 2. LICENSE GRANT TO CLOUDFLARE

> By submitting, posting, or publishing your content, suggestions, enhancement requests, recommendations, feedback, information, data, or comments (“Content”) to any Website or Online Service, you are granting Cloudflare a perpetual, irrevocable, worldwide, non-exclusive, royalty-free right and license (with the right to sublicense) to use, incorporate, exploit, display, perform, reproduce, distribute, and prepare derivative works of your Content.

https://www.cloudflare.com/en-gb/website-terms/

That's incorrect. See:

> THESE TERMS DO NOT APPLY TO YOUR ACCESS AND USE OF THE CLOUDFLARE PRODUCTS AND SERVICES THAT ARE PROVIDED UNDER THE SELF-SERVE SUBSCRIPTION AGREEMENT, THE ENTERPRISE SUBSCRIPTION AGREEMENT, OR OTHER WRITTEN AGREEMENT SIGNED BETWEEN YOU AND CLOUDFLARE (IF APPLICABLE).

ZTNA tunnels only work with a cloudflare account, so they're subject to the self-serve subscription agreement.

> You and your End Users (as such term is defined in the Privacy Policy) will retain all right, title and interest in and to any data, content, code, video, images or other materials of any type that you or your End Users transmit to or through the Services (collectively, “Customer Content”) in the form provided to Cloudflare. Subject to the terms of this Agreement, you hereby grant us a non-exclusive, fully sublicensable, worldwide, royalty-free right to collect, use, copy, store, transmit, modify and create derivative works of Customer Content, in each case to the extent necessary to provide the Services.

I think you might be confused by the two licenses applied to different type of services:

https://www.cloudflare.com/terms/

https://www.cloudflare.com/website-terms/ <- this one you quoted explicitly said it does not cover the one above, which applies to CDN/tunnel/etc

True - wrong quote. But the other has equivalent terms, albeit with a service based restriction. It indicates a lack of confidentiality in the data.

No it does not. Twice already you've written false information, and thrice already you've been corrected by others. Why not read the actual texts before posting?

I love CF tunnels I use it to “expose” some internal services that are gated with google auth and other zero trust protections. I don’t have to worry about exposing ports or using a vpn.

Can you do the same thing with tailscale funnel?

Old guide. These days it's a copy and paste from the dash. You can also PIN protect the subdomain with Access.

(2022)

Still relevant, and always new to someone.

Posts on hn that are not from the current year should have that information in the title. If it is missing, users post the year in parentheses.

That’s a fair thing to include for posts from a prior year.

A post that is new to everyone vs new to some might save a few clicks.

I was commenting on the post still having relevance despite the age, or without the year.

Edit: typo

This looks AMAZING! Will be doing this for an upcoming project.

This is great, will definitely have to try this out

Has anybody used this to run a private email server?

I'm pretty sure you cannot do so with this Cloudflare tunnels, or similar as MX records must expose a public IP address.

You can have Cloudflare forward traffic via a tunnel I think.

Pangolin

Pangolin could be a great open source alternative if you prefer to self host the server component. You could even set up WAF with CrowdSec which is awesome

Show HN: Pangolin – Open source alternative to Cloudflare Tunnels

https://news.ycombinator.com/item?id=44526015 (yesterday, ~120 comments so far)

Reply on news.ycombinator.com