Assuming the user will not be connecting over vpn, but is both remote and non-technical, how would you expose Jellyfin to them securely?
deleted by creator
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.
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. 🤞
The plugin was neat, but if the clients don’t support it, it’s pretty much useless.
Mobile clients should use QuickConnect for it (statement by the sso plugin maintainer). Else it should work with everything that uses the WebUI.
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.
What exactly about jellyfin makes this oidc style access more difficult to manage?
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.
Which plugin?
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.
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
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.
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?
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.
Afraid people will use known vulnerabilities in common self-hosted software.
Well yeah, the “good as you can get” answers are “use a VPN” or “don’t”.
So every answer is as good as you can get?
I suppose it depends on what you mean by “good as you can get”.
Run the jellyfin in a container that only has read privileges to the videos ( make sure you can’t get out to your whole NAS from there), put that behind a Cloudflaired tunnel.
It’s not technically secure, but if they can’t get a foothold in your network and the only thing they can access is your video catalog, that’s a reasonable amount of risk.
Gotta be careful with cloudflared and media. They can block you if they detect copyrighted materials, even if it’s your own DVDs. You can setup TLS certs so the traffic is at least encrypted
If your American, ripping your own DVD’s still isn’t legal.
Right. Which is why Cloudflared would block you if it’s detected. But regardless, if for whatever reason, you ended up in court for the content you copied, the judge would probably give you a low fine. Obviously not legal advice, but the US justice system doesn’t have time to care about people making digital copies of DVDs they’ve purchased.
It’s irrelevant anyway, since none of us are just copying our own DVDs… But for legal reasons /s
Just make sure you disable caching or it can be a bit slow
Another way:
Expose using caddy. Use basic auth for the web UI only. This exempts the Jellyfin app clients from basic auth that they don’t support but requires it before anyone even gets to the Jellyfin UI. This obfuscates the fact that your endpoint is even a Jellyfin end point.
How can I do that? I’d love to have better security for my jellyfin but I risk breaking the apps.
A reverse proxy is what you are looking for. I recommend Caddy.
You’ll also need a domain, but they can be had for very cheap.
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.
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.
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.
@KneeTitts @Jason2357 Recently there are a lot of zero-day kernel exploits (local privilege escalation), so I would make sure “up to date” includes regular reboots into new kernels. As opposed to just relying on something like unattended-upgrades.
For the past few weeks we’ve been averaging one LPE per week, and it’s probably going to continue like that for a bit.
At the very minimum stick a reverse proxy in front like caddy, nginx, or Traefik. Then have some middleware like crowdsec to inspect what’s going on. Then whitelist the IP or the country IP block.
There is much more but those would be the bare minimum.
I too would like to know more. Jellyfin has been something that I am still heditating to expose online without a VPN.
I have Plex behind a reverse proxy (HAproxy) with Crowdsec and firewall rules all behind Cloudflare. My firewall rules in HAproxy block access a few different ways, like if request are higher then 60 requests a second, or if there is strange path traversal. Used the following guide as a start.
https://www.archy.net/building-a-native-fail2ban-with-haproxy-stick-tables/
If client certificates and basic auth is not supported by jellyfin:
- reverse proxy
- strong random subdomain
- wildcard certificate
- tls1.3 only
- doh/dot only
1-3 make random scanners unable to find your service, 4&5 even hide it from your ISP. Dot/doh service will still know your subdomain, so be your own dot/doh ! :D
Throw in port knocking for good measure.
You telling me jellyfin Clients can’t handle client certs but can port knock?
My proposal is for maxing ux on the client side while being properly hidden.
No you port knock first to open the ports. Then connect the client.
usually port knocking opens the relevant port to the client IP that is knocking. So it makes a lot of sense to have the knocking done by the requesting client. In many situations knocking from your mobile while behind the same NAT as your jellyfin client will do the trick, but if you have different IPv6 on those devices etc, it won’t.
Also: if you assume your DNS lookups are sniffed - so are your port knocks. If you don’t, spare the extra work. But then, if you like port knocking - keep knocking, nothing wrong about it :D
I’m no expert, but an unguessible URL path is similar but not visible to DNS. Could do both.
If jellyfin Clients can do URLs, sure
My use cases are:
- Connect from multiple devices on the same home network (with the application)
- Connect from a phone device on the internet (with the application)
- Connect from some PC’s and devices on the internet (with the application and from web browser)
For home networked devices, I don’t care about security that much. I try to lock it down on the router level and by using VLANs for less secure devices. I connect via IP directly (or .local domain).
Jellyfin runs under its own user with read access to a media library.
For devices on the internet, I have jellyfin exposed on a specific url path of my domain - through a reverse proxy all through 443. A bit of security through obscurity here. I’m proxied through cloudflare on the DNS side with very restrictive IP rules.
I think this is enough for the security flaws jellyfin does have. I’d sleep better at night if it had client certificate support, but Its not a big deal imo. If security flaws allowing remote code execution are found, I’ll shut it down and allow access through wireguard only and lose access from some devices on the internet where I cant use VPNs. Not a bit deal either.For 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.
Also not as ideal if their ISP uses CGNAT. Still waaay better than fully open, but you would be giving access to many households
Yep, 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.
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.
No, not for remote access over the internet.
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.
Just 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
It really seems overblown of an issue…
Reminds me of
Except most people have almost the same structure because of media organizers like radarr/sonarr. At the very least they should hide that behind a setting to not require auth (since the header should be there for most clients) so only people running an old client would be affected. They could also add an extra salt to that hash or something similar.
I agree, it’s not critical, but it shouldn’t be hand waved either. And like I said, security is relative, I would argue for most people this is fine, but I still think this should be taken more seriously.
Yeah not only would a lot of people have the same media name, because of docker mounts, probably a lot of people have the same path to the media inside of the docker container even if the external location is different. I bet you could make a rainbow table of sorts of the most popular movie/TV torrents combined with the most common place in the container for media to be mounted, then use shodan to get a list of hundreds of instances that you could scan for the common hashes.
I’m just seeing the issue for the first time and noticed it was raised 5 years ago - surely that was enough time to at least put forward a changeover date and give clients time to update.
Jokes on them, my paths are a shitshow and I can’t be bothered to organize them properly
Do you not do any renaming? That probably would make it even easier as you can just brute force with a database of filenames scraped from torrents. I already have a proof of concept that generates valid jellyfin IDs from any given file path, it only takes a few more steps before you can plug in a shodan scan of jellyfin instances and just shotgun a bunch of IDs generated from torrents.csv at them and find stuff you can stream without authentication.
People not bothering to rename, using the default radarr naming scheme, or everyone using the same naming pattern from trash guides just makes it easier.
I was mostly making the comment in jest. I do rename, but my folder structures, as someone who downloads everything manually based on what I want to watch rather than doing the automated *arr stuff leaves it in directories only I consider sensible.
I have Jellyfin behind a reverse proxy that lives in a DMZ and a WAF to go with it. I’m sure there’s still room for watching an unauthenticated stream because I forgot to rename a folder somewhere, but it’s not exactly an attack vector I care about. I’m more concerned about DDoS or impersonation attacks, which I also attempt to mitigate via an LDAP implementation behind the scenes.
It’s not perfect, but it’s the best effort I can make at the moment.
Yeah that’s fair and I think that’s a good move, my point is just that people are acting like this is not feasible to exploit. I’m at the point in my exploit testing excursion where I have a script that can generate a stream of potential IDs based on real torrent names being parsed and reformatted using radarr’s default naming pattern as well as the commonly used trash guides ones permuted with some common library paths used in the default docker compose examples, and it’s turning up actual ID matches with my jellyfin instance. All I have left to do is make it create API requests to test the IDs against the unauthenticated API instead of checking an exported list and there’s a proof of concept. 5 years is a long time for someone to figure that out.
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.
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.
There’s zero need to run Plex in a docker container.
There’s zero need to run anything in docker, it just makes things easier and portable.
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.
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.
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.
It’s exactly what it sounds like.
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?
This is solid. I wonder if you could rig up a ddns somehow to keep it seamless?
