Assuming the user will not be connecting over vpn, but is both remote and non-technical, how would you expose Jellyfin to them securely?
- pnelego@lemmy.worldEnglish1 month
To be totally honest I’m not sure you can harden jellyfin enough for public Internet exposure without also breaking basic functionality of the platform.
This is why everyone is always pushing so hard for a VPN/Tailnet of some kind. The public internet is a bit to much of a wild west to be exposing arbitrary services to it unless you really know what you’re doing.
- Nibodhika@lemmy.worldEnglish1 month
Secure is relative, you should be aware that jellyfin itself has security issues https://github.com/jellyfin/jellyfin/issues/5415 most of which are harmless, but at least one is fairly serious and allows people to watch your media without authentication, and adding an extra layer of authentication on the proxy would likely cause issues with clients.
That being said, if you’re okay with those security issues what I would do is have a cheap VPS, connect both machines to tailscale, and have something like Caddy on the VPS to do the forwarding.
exu@feditown.comEnglish
1 monthJust leaving this here
Now, let’s address this clearly once and for all. What is possible is unauthenticated streaming. Each item in a Jellyfin library has a UUID generated which is based on a checksum of the file path. So, theoretically, if someone knows your exact media paths, they could calculate the item IDs, and then use that ItemID to initiate an unauthenticated stream of the media. As far as we know this has never actually been seen in the wild. This does not affect anything else - all other configuration/management endpoints are behind user authentication. Is this suboptimal? Yes. Is this a massive red-flag security risk that actively exposes your data to the Internet? No.
https://github.com/jellyfin/jellyfin/issues/5415#issuecomment-2825240290
- FreedomAdvocate@lemmy.net.auEnglish1 month
Isn’t it hilarious that the best solution to do remote streaming using the free software that people use because they don’t want to pay for a Plex subscription or one-off cost is to pay for at least one subscription, maybe more?
It’s almost like the reason Plex charge money is because it’s not free to do.
- Nibodhika@lemmy.worldEnglish1 month
What Plex does is closer to having an embedded tailscale client, you can access Jellyfin remotely with tailscale for free, but OP specifically asked for no VPN.
That being said, I’m not opposed to Plex charging for that service, even a tailscale like server costs something to maintain. My gripe with Plex is that it purposefully shoots itself in the foot to force you into their paid service, i.e. it actively tries to isolate itself so you can’t access it remotely, which means that it can’t run inside a docker container unless you give it network host access, otherwise it only considers other docker containers locals and doesn’t let you watch your own content from another machine in the same network.
- Nibodhika@lemmy.worldEnglish1 month
There’s zero need to run anything in docker, it just makes things easier and portable.
- FreedomAdvocate@lemmy.net.auEnglish1 month
Plex server doesn’t need to be “portable”, and running it in docker definitely doesn’t make it easier.
There absolutely are programs that make sense to run in docker, but Plex server isn’t one of them.
- Nibodhika@lemmy.worldEnglish1 month
Plex server doesn’t need to be “portable”
Strongly disagree, I’ve switched my media server several times in the past decade for a multitude of reasons, having things in docker has allowed me to do this seamlessly.
Also you’re ignoring all of the other benefits of running in docker, from isolation to automation.
and running it in docker definitely doesn’t make it easier.
Plex is the only self-hosted service that is purposefully trying to block you from being ran in docker. All other things are just much easier to run in docker, that’s part of the appeal, reproducible builds eliminate the “it works on my machine” errors.
There absolutely are programs that make sense to run in docker, but Plex server isn’t one of them.
Why do you think it doesn’t make sense? Does Jellyfin make sense to you to run in docker? Why are they different?
Also, Plex only supports Ubuntu and CentOS, none of which I run on my server, so the only OFFICIAL way to run Plex is Docker.
- 1 month
I’m kinda disappointed with this thread, I’m in a similar position to OP, but all the responses are just like “use a reverse proxy and make your URL hard to guess” and other measures which are not very secure. \
It seems like that’s about as good as you can get at the moment, because the mobile apps barf if you try to add in auth in front of the reverse proxy, but a lot of people seem to be providing this advice like it’s good enough rather than as good as you can get.
- KneeTitts@lemmy.worldEnglish1 month
Im confused as to what people think the security issue is? Do they think someone will brute force their username and password with a billion queries?
- mko@discuss.tchncs.deEnglish1 month
That’s assuming an attacker will play nice with URL forming and discovering edge cases in POSTing shaped data to the service. Just encrypting is still weak security if the whole front-end web and API surface isn’t hardened.
- 1 month
Afraid people will use known vulnerabilities in common self-hosted software.
- KneeTitts@lemmy.worldEnglish1 month
Sorry but are you guy not using Linux as your servers? Windows? Now I understand.
- 1 month
Did you just suggest Linux has no vulnerabilities in any of its distros, and neither does any of the self-hosted services?
- Encrypt-Keeper@lemmy.worldEnglish1 month
The biggest problem with that Jellyfin to this day is that you can’t.
Seems like every new open source selfhosted app implements OIDC compatibility, but for some reason, I can only assume is technical debt, Jellyfin hasn’t.
- kiol@discuss.onlineEnglish1 month
What exactly about jellyfin makes this oidc style access more difficult to manage?
- Encrypt-Keeper@lemmy.worldEnglish1 month
Jellyfin just doesn’t have it, period. There’s a third party plugin that will kind of tack it on to the Webui, but none of the Jellyfin apps will work with it.
- 1 month
Jellyfin had a third party plugin for OIDC. It was archived recently, but I heard Jellyfin has plans to implement it directly into the software. 🤞
- Encrypt-Keeper@lemmy.worldEnglish1 month
The plugin was neat, but if the clients don’t support it, it’s pretty much useless.
- 1 month
Mobile clients should use QuickConnect for it (statement by the sso plugin maintainer). Else it should work with everything that uses the WebUI.
- Encrypt-Keeper@lemmy.worldEnglish1 month
Quick connect is not SSO. Because the topic is about non-technical end user friendly solutions, this isn’t a great one because this requires your user to login using a web browser on a different device and then use that for the quick connect and it’s just more clunky than it should really be.
It’s honestly easier in this situation to just configure your end users device with a mesh VPN like Tailscale or Netbird and then all they ever have to do is login with whatever password you gave them.
- zaggynl@feddit.nlEnglish1 month
Ask them to visit https://ipv4.icanhazip.com/ and give you back the number, then whitelist in your webserver, as well as your LAN/VPN range, deny rest. Explain they can only reach jellyfin from their home internet. Repeat if they get 403 forbidden after they get a new WAN IP.
That or VPN like openziti, wireguard but gets more complicated.
- axx@slrpnk.netEnglish1 month
You really can’t assume your visitors are going to have static IPs.
What happens when they visit from their phone? A friend’s WiFi? Their home connection that has a regularly changing IP?
- zaggynl@feddit.nlEnglish1 month
So far I’ve seen WAN leases expire after a long time, say months, or quarter year, so is doable. If becomes an issue I’ll work with them on a VPN solution but is a pain for non-technical users or non-supported hardware. That’s also why I explain “use from your home network only”.
- axx@slrpnk.netEnglish1 month
What’s your concern about running it behind a reverse proxy, like caddy or nginx?
- zaggynl@feddit.nlEnglish23 days
I don’t consider Jellyfin a fully secure and audited application to host, unsecured endpoints come to mind, that and the less exposed to the whole internet the better.
https://github.com/jellyfin/jellyfin/issues/13987
Things like these scare me:
https://blog.lastpass.com/posts/notice-of-recent-security-incident
- hereiamagain@sh.itjust.worksEnglish1 month
This is solid. I wonder if you could rig up a ddns somehow to keep it seamless?
- zaggynl@feddit.nlEnglish1 month
Something like reverse dynamic DNS for end users? Hm, only if it would be easy to setup, is on the same level as a VPN client I’d say.
- 1 month
best practice states security through obscurity is not to be relied upon, but compare ssh logs after one year on the default port vs a non-standard port and you’ll immediately see why you want to use a non-standard https port for non-professional services. it cuts 99.9% of the noise/attempts.
- Jason2357@lemmy.caEnglish1 month
Put Jellyfin and a reverse proxy in an isolated vlan or DMZ, with no ability to reach into your lan at all and everyone connects in the same way. Its just movies, thats all you lose if it gets hacked. Set up some monitoring too in case it becomes a botnet node so you can destroy it and start over.
- KneeTitts@lemmy.worldEnglish1 month
Are the majority of you running jellyfin on windows? All of this reverse proxy stuff sounds incredibly paranoid to me and 99% of zero day exploits would be very unlikely to fully compromise up to date linux servers.
- Jason2357@lemmy.caEnglish1 month
The reverse proxy is just to give it TLS with a let’s encrypt cert. If you are running an internet facing web application without TLS, Windows is the least of your concerns.
katy ✨@piefed.blahaj.zoneEnglish
1 monthif theyre close, add them to your tailscale, if not and you have a web serve, use a reverse proxy.
for tailscale, you’d probably have to walk them through setting it up but then its one and done
NeryK@sh.itjust.worksEnglish
1 monthFor a remote and non-technical user I would say IP whitelisting offers a decent tradeoff.
On your end you expose your jellyfin port to internet, but restrict at the router level to your user’s client IP address as soon as you have it. Obviously in practice this works best if the address does not change often.
- Bazoogle@lemmy.worldEnglish1 month
Also not as ideal if their ISP uses CGNAT. Still waaay better than fully open, but you would be giving access to many households
NeryK@sh.itjust.worksEnglish
1 monthYep, that’s why I call that a tradeoff. Far from perfect and yet so much better than nothing.
Pros:
- Likely cuts 99.99% of attacks.
- Nothing to do on client’s end.
Cons:
- Whitelisting must be updated everytime the client address changes.
- Not 100% bulletproof as operators (notably for mobile networks) can NAT multiple connections behind a single publicly addressable IPv4 address.
- Also IP addresses can be spoofed but I doubt that would be a major concern here.
- MIDItheKID@lemmy.worldEnglish1 month
Is there a way to this with like a MAC address instead of an IP? Allowing specific devices (my parents have a Firestick that they travel with) would be pretty ideal.
- Seefoo@lemmy.worldEnglish1 month
You can do a reverse proxy + authelia (or other auth service). It’s still more risky than a VPN IMO, buts wayyyy better than some of the other options in this thread
- 1 month
Depends on what you mean by “secure.” My personal setup is Jellyfin LXC on proxmox --> Wireguard to VPS -> Nginx reverse proxy on VPS.
This setup relies somewhat on Jellyfin’s auth, but I’m comfortable with that risk. The LXC is blocked from sending local traffic on my network by firewall rules. Yes, someone could exploit a vulnerability in Jellyfin (though looking through the CVEs I’m not overly worried about that), then escape the LXC and fuck with my server. But that’s a lot of work for no profit.
For more protection (in sense of reducing traffic that even interacts with your server), I’d recommend getting a wildcard cert for the domain so that the actual subdomain jellyfin is on is undisclosed to anyone not using your service.
Security isn’t about making everything impregnable, it’s about making attacks more trouble than they’re worth. Otherwise, we’d all live in fortified bunkers surrounded by landmines. 🙃
- atzanteol@sh.itjust.worksEnglish1 month
Your vps isn’t doing anything useful security wise… it’s just sending traffic directly to jellyfin.
You’d get the same protection with just port forwarding to a local proxy in front of jellyfin. Or you could even leave out the proxy if you didn’t need it.
- 1 month
I’m aware of this (that’s why I described a potential breach as Jellyfin -> LXC escape). What it does provide me is a static IP to point my domain at that I don’t have to worry about updating via whatever DDNS service and that isn’t tied to my home address. That and the wireguard tunnel gives me plausible deniability should my ISP ever decide to enforce its rules against hosting servers. 😀
- eli@lemmy.worldEnglish1 month
How much bandwidth is used via the VPS in this instance? I’ve seen most VPS in the USA have a limit of 1TB of bandwidth.
How many users are you sharing with?
I know Hetzner does 20TB bandwidth, but that is only EU servers as far as I know.
- 1 month
I have a very cheap ($11/yr) us-based vps through racknerd I got via low end box. I’ve got 12 users but only 5 really active ones and I’ve never come close to hitting the 1tb transfer. I serve several services through that one vps (all just reverse proxy to my homelab).
I did just pick up another u.s. based vps through low end box the other day- $12/yr and unmetered Gbps. 1 CPU only, but a reverse proxy doesn’t need a lot of compute. :)
- 8j1obzlb@piefed.socialEnglish1 month
I agree with the folks saying reverse proxy of some kind + WAF. That way end users don’t have to deal with the VPN, but your home system is not directly exposed.
I’ve been doing something similar with SSH local port forwarding and a $5/month VPS. Haven’t come anywhere close to my network quotas, and performance has not been an issue for home use with 2-5 concurrent users most of the time. I forward the local caddy ports to unprivileged ports/user on the VPS, then use the firewall on the VPS to forward that port to 443 and lock down the rest.
- FreedomAdvocate@lemmy.net.auEnglish1 month
With a single year of those VPS costs you could have just bought a plex lifetime pass on sale lol
Avoiding paying a one off fee or subscription by paying a different subscription for a more complex and worse product is amazing.
- Evotech@lemmy.worldEnglish1 month
I just type the URL
I have Cloudflare set up without Auth. Just region locked to my country
So it’s just a solid reverse proxy with a bunch of features and an added layer with white listing.
I know whitelisting isn’t security per say but it’s good enough
- 1 month
Idk if geo whitelisting is really good enough. I can’t speak for OP, but I’m in the same position and I don’t. I had high hopes for the post but everyone seems to just brush over the “secure” part
- Evotech@lemmy.worldEnglish1 month
What are you afraid of?
My jellyfin runs in a a rootless podman container
- 1 month
I’m afraid of security bugs in the software I’m using, so that containers don’t contain, read-only doesn’t prevent writing, mounting directories doesn’t restrict access to those directories, etc.
I’m a nobody, I can’t imagine anyone targeting me or my random domain, but I can imagine getting swept up in a net of attacks of opportunities targeting hosted software with known vulnerabilities, or injected supply chain vulnerabilities, so I want to reduce my attack surface as much as I can (while still actually letting the people I want to access it actually access it)
- BandDad@lemmy.zipEnglish1 month
If anyone has any tips for getting Tailscale running via Docker on my Openmediavault machine, I’m open to it. Everyone lauds it for being dead simple and I cannot for the life of me get it running on the machine it needs to be. Not sure my wife can/will handle anything more complicated.







