Comment on Self hosting with subdomains
VeganCheesecake@lemmy.blahaj.zone 1 day agoGood as a general recommendation.
I also feel like the risk levels are very different. If it’s something that performs a function but doesn’t save/serve any custom data (e.g. bentopdf), that’s a lot easier to decide to do than something complicate like Jellyfin.
I do have public addresses for Matrix, overleaf, AppFlowy, immich because they would be much less useful otherwise. Haven’t had any problems yet, but wouldn’t necessarily recommend it to others.
I’d never host any stuff with “Linux ISOs” on a public adress, that seems like it’d be looking for trouble.
frongt@lemmy.zip 1 day ago
Doesn’t matter. Any exposure risks compromise. From there, an attacker could pivot to read your data, mine cryptocurrency on your device(s), serve objectionable material, or other unsavory activities.
Even if you have authentication enabled, not all APIs require authentication. Jellyfin in particular is not designed to be internet-facing. And even if it does require authentication, authentication bypass attacks are a thing.
jtzl@lemmy.zip 22 hours ago
If you really want to secure your computer, encase that puppy in concrete (after disconnecting it from power),
Magnum@infosec.pub 1 day ago
What do you mean JellyFin is not designed to be Internet facing??? jellyfin.org/docs/general/…/networking/
frongt@lemmy.zip 1 day ago
github.com/jellyfin/jellyfin/issues/5415#issuecom…
Appoxo@lemmy.dbzer0.com 1 day ago
Designed meaning in that case intended to be exposed.
More of an internal thing.
VPNs on the other hand are designed to be exposed. Same with some ssh servers or reverse proxies like traefik, nginx etc.
Magnum@infosec.pub 1 day ago
So you mean the JellyFin ports should not be directlly exposed, but self hosting and exposing nginx to forward the traffic locally to jellyfin is fine?
VeganCheesecake@lemmy.blahaj.zone 1 day ago
… sure. Nothing here is wrong, but there’s ways to try and mitigate that. And then it’s kinda an arms race, and vigilance.