zlacker

[parent] [thread] 8 comments
1. Schema+(OP)[view] [source] 2026-01-12 01:04:15
Even if you understand what you are doing, you are still exposed to every single security bug in all of the services you host. Most of these self hosted tools have not been through 1% of the security testing big tech services have.
replies(3): >>johnis+KD >>bjt123+Nm1 >>IgorPa+eW1
2. johnis+KD[view] [source] 2026-01-12 06:40:45
>>Schema+(OP)
Now you are exposed to every security bug in Tailscale's client, DERP relays, and coordination plane, plus you have added a trust dependency on infrastructure you do not control. The attack surface did not shrink, it shifted.
replies(1): >>Schema+Zn3
3. bjt123+Nm1[view] [source] 2026-01-12 12:45:41
>>Schema+(OP)
How would another service be impacted by an open UDP port on a server that the service is not using?
4. IgorPa+eW1[view] [source] 2026-01-12 15:39:24
>>Schema+(OP)
For every remote exploit and cloud-wide outage that has happened over the past 20 years my sshd that is exposed to the internet on port 22 has had zero of either. There were a couple of major OpenSSH bugs but my auto updater took care of that before I saw it on the news.

You can trust BugCorp all you want but there are more sshd processes out there than tailnets and the scrutiny is on OpenSSH. We are not comparing sshd to say WordPress here. Maybe when you don’t over engineer a solution you don’t need to spend 100x the resources auditing it…

replies(1): >>lillec+6C2
◧◩
5. lillec+6C2[view] [source] [discussion] 2026-01-12 18:43:14
>>IgorPa+eW1
If you only expose SSH then you're fine, but if you're deploying a bunch of WebApps you might not want them accessible on the internet.

The few things I self host I keep out in the open. etcd, Kubernetes, Postgres, pgAdmin, Grafana and Keycloak but I can see why someone would want to hide inside a private network.

replies(1): >>IgorPa+FY2
◧◩◪
6. IgorPa+FY2[view] [source] [discussion] 2026-01-12 20:31:07
>>lillec+6C2
Yeah any web app that is meant to be private is not something I allow to be accessible from the outside world. Easy enough to do this with ssh tunnels OR Wireguard, both of which I trust a lot more than anything that got VC funding. Plus that way any downtime is my own doing and in my control to fix.
◧◩
7. Schema+Zn3[view] [source] [discussion] 2026-01-12 23:09:21
>>johnis+KD
I run the tailscale client in it's own LXC on Proxmox. Which connects to nginx proxy manager also in it's own LXC, which then connects to Nextcloud configured with all the normal features (Passkeys, HTTPS, etc). The Nextcloud VM uses full disk encryption as well.

Any one of those components might be exploitable, but to get my data you'd have to exploit all of them.

replies(1): >>johnis+zu3
◧◩◪
8. johnis+zu3[view] [source] [discussion] 2026-01-13 00:13:19
>>Schema+Zn3
You do not need to exploit each layer because you traverse them. Tailnet access (compromised device, account, Tailscale itself) gets you to nginx. Then you only need to exploit Nextcloud.

LXC isolation protects Proxmox from container escapes, not services from each other over the network. Full disk encryption protects against physical theft, not network attacks while running.

And if Nextcloud has passkeys, HTTPS, and proper auth, what is Tailscale adding exactly? What is the point of this setup over the alternative? What threat does this stop that "hardened Nextcloud, exposed directly" does not? It is complexity theater. Looks like defense in depth, but the "layers" are network hops, not security boundaries.

replies(1): >>butvac+IT7
◧◩◪◨
9. butvac+IT7[view] [source] [discussion] 2026-01-14 05:51:52
>>johnis+zu3
And, Proxmox makes it worse in this case as most people won't know or understand that proxmox's netoworking is fundamentally wrong: its configured with consistent interface naming set the wrong way.
[go to top]