Cloudflare tunnel + docker, how to secure?
hey so I'm using a cloudflare tunnel with a docker container, and I've noticed that anyone who has access to my account (yes, I've set up 2FA, but still) can configure my tunnel and change the forwarded port to literally any port on or off of my home network(s). is it possible to either:
a. restrict it so that only locally can I change what's being forwarded through the tunnel
OR
b. block local IPs on certain subnets and/or entire adapters from being accessed by docker
so that I can make sure no one can access my local network or any of my devices? thanks in advance.
I'm really happy with how easy Cloudflare tunnel is to set up, but I'd like to stay secure.
18 Replies
Nothing native in cloudflared, you'd have to do something with docker or with some other firewall rules/firewall utility like ufw.
makes sense to me, what kind of rules would that be?
i did figure it would involve something like ufw
is it possible to do a locally-managed tunnel and provde just one ip and port to cloudflared that way? i didn't realize there were both locally and remotely managed tunnels
you can use a local tunnel with a config yea. They're much more annoying to use/config,have to create the dns records separately or via command, and have to use yaml, but it is a option
https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/get-started/create-local-tunnel/
ah, i see.
tbh I haven't thought too much about the risk of account take over, I think generally for most people there's a lot worse things they could do if they hacked your CF account rather then trying to randomly port scan/mess around with tunnels. CF supports security keys and such as well
Just curious, can you use domains owned by different cloudflare accounts using a locally managed tunnel and manually setting the dns records?
no
you can only cname to tunnels that belong to your account, can't cname/use tunnels belong to a diff account
that is true in many cases, especially for bigger sites, but since this is just a personal dev site this would probably be on the worse side, aside from maybe payment related things
Aw, okay. Thanks
i guess if i am really set on being as secure as possible, i could make one docker container running cloudflared with a locally managed tunnel, and then make another one the web server, and have the web server connect with cloudflared
yea I think if you're set on being as secure as possible you should isolate cloudflared/the web server as much as possible from other parts with strict acls
how would i do acls in this case?
is that a ufw thing? or something on cloudflare's end
It depends on your setup? I'm no docker guy, I ufw and use tailscale's ACLs for most of my stuff
i will have to learn ufw
does cloudflare have something like tailscale ACLs?
nothing for public hostnames like that
tailscale is more generic, doing supporting any tcp/udp protocol, acls make more sense
even with tailscale though you set the ACLs in the dash so if your acct is compromised you're run into the sameish issue. Although they have some more controls with needing separate auth for adding new nodes/devices
so how would i do acls as you've said here? excluding docker-specific steps
the cloudflared docker container should only be able to connect to the internet (might even be able to restrict it to cloudflare) and the web server, no other internal stuff
Local configs aren't a bad idea for full control either, and also let you more easily use replicas/duplicate cloudflared instances for redunancy
yeah, i was thinking use docker to give those two containers a shared network of some sort, and then somehow have ufw block access from either of these containers to the server ip on the network
so that we're safe on the client side
and on top of that yeah have the cloudflared container use a local config so that we're safe on the account side/nothing can be changed there
at that point the only thing i'm worried about is the containers accessing other devices on the network like the router's control panel etc
the "lazy way out" here being perhaps running a vm, purposefully not giving the vm direct access to the router, and just blocking access from the vm to ports like 21/22 on the host using ufw but that's just overkill