by tech234a 4 days ago
Can anyone comment on the security of Jellyfin? When I had last looked into it, it seemed like Jellyfin had a somewhat weak security model that made me question switching family members to it from Plex.
Don't expose it to the internet unless you know what you're doing, or put it on a VPS you don't care about.
Ideally keep it behind a VPN and give your family members access to it that way, and let local devices on your LAN connect to it without a VPN.
Those are fine ideas.
But I'm not all about getting something like Tailscale to work with my elderly mother's Roku device, nor teaching her how to use it.
Get your elderly mother an Apple TV and infuse, then connect with Tailscale. It’s pretty friggin’ smooth in daily operation. Apple TV’s UI is no easier to get lost in than Roku, and actually has fewer pitfalls if you toggle one setting (the one that makes one home tap open the Apple TV app, and a second press while in that app actually go home, by default; switch that to always go home on any press of that button no matter what)
I dunno if Tailscale works on Roku but otherwise that would indeed be entirely viable too, last I saw Jellyfin’s app on there is really good. Likely need a server powerful enough to transcode, though, lots of (all?) Roku devices don’t have hardware decoding for newer codecs like h.265. That’s one big benefit of an Apple TV, it can hardware decode damn near everything.
Perhaps.
Y'all (collectively) have some good ideas.
But she likes the Roku. She's even got silicone skins for the remotes (plural; spares!), and two of them are tethered near the chairs that her and dad tend to sit in.
Also: The Roku stuff already exists, and is paid for, and it works with Plex (without a VPN, because my local Plex container didn't come with the caveat to avoid exposing it to the world).
Buying them one or more Apple TV devices to use instead seems expensive and likely to fail somehow.
Switching them to (cheap? linux?) PCs also sounds expensive and bad, particularly with my dad. He's certainly had more years to learn how to use a computer than I have, but he's spent most of the recent decades deliberately avoiding them. He hates them, and he doesn't want to learn them. He'd fall apart and give up on television entirely if I gave him a PC with a slick Logitech K400 to run it with. (He can drive a Roku with Youtube TV and Plex like a pro, but that's mostly only a D-pad and a back button.)
---
But since you and others have mentioned it: Transcoding. That's really not a big problem for many vaguely-recent PCs. With Plex, at least: The quite old i7-6700k desktop box I use for this transcodes to h.264 like a beast using its paltry iGPU, and does h.265 just fine with an old nVidia RTX 2080 if I elect to use that instead. Either way works well and never breaks a sweat.
It may have been a powerful machine a decade ago, but a used computer with a 6700k (or so) to serve media with is cheap these days. (And a brand-new power-sipping N150 box does transcoding waaaay better, even in credit-card form factor.)
A couple of other options:
If their router supports it, configure the VPN there so it's available for the entire network.
Set up a Raspberry Pi (or similar) on their network that is configured with the VPN and runs a reverse proxy to expose the Jellyfin instance.
But yeah, either of those is going to increase your support burden.
Sad to hear about people getting stuck in weak ecosystems.
By the way, I switched from Jellyfin to plain SMB + Nova Player (Android), which has basically the same interface, but no user profiles, and works over SMB, obviously. No transcoding, best format support, and best performance for large files I've found yet for my TCL Android TV.
I mean, for my TV at home where everything is connected with a gigabit LAN, I usually use Kodi on a Pi4, over SMB, with a Logitech KT400 to drive it from wherever I feel like sitting.
It's silent, reasonably self-contained, and is appliance-like to get going (just dump OpenELEC onto an SD card, plug everything in, and then simply begin using it).
Plus, there's two HDMI outputs: One that connects directly to the the dumb TV and sends only video, while the other sends only lossless PCM audio to the once-rather-high-end AV receiver (that gets choked up on more-modern HDMI bitrates).
And that's great for me at my house, with my pile of gear, and with my technical proclivities.
But I'm not my mom, and this isn't my mom's house. :)
I use Jellyfin and when it works it’s great but a few small things make it totally unusable for a non-technical family member.
One thing is when it can’t see the server it doesn’t just say it can’t see it, it acts like the issue is you’re not logged in and then when you log in (having to type your password manually each time, on a TV) it then fails.
This is only really diagnosable if you can access both the client and server and is a complete failure and very tedious experience if you only have client access.
Feels like I experience this at least once a month so couldn’t ever set this up for family members remotely.
I set my dad up with a Linux box as a daily driver for him - he keeps the desktop on , and the roku jellyfin now has a clean proxy into jellyfin over the tailscale network. Giving him a desktop I can remote into was a great decision that paid dividends for him :)
You can point Tailscale toward a $5 exit-node VPS and Caddy/nginx through a cheapo-but-memorable-domain to get a Jellyfin Dashboard up in a browser. I assume running the domain and port through the Jellyfin Roku app would work fine (can't be sure as I've never used a Roku).
Just mind your ACLs
I put mine behind caddy on a long unguessable path prefix. So that acts as a sort of password that you need to know before you can access it at all. So far it's seemed to work great. The advantage to using a path prefix vs like caddy basic auth is that its compatible with all the normal jellyfin clients.
You can also use HTTP auth with your reverse proxy and it works with all Jellyfin clients
TLS is a must-have. They don't bother doing any kind of password hashing on login. It's sent in cleartext.
That's no different from how just about any other webapp works.
"Bothering" with client-side password hashing, in the absence of TLS, is security theater. It provides only the most trivial protection against eavesdroppers.
If someone can steal an unhashed password, then they can also steal whatever hash you send instead. If you try to fix this with some kind of ad-hoc challenge-response protocol, then the attacker can just steal your session cookie after login.
There shouldn't even be a question of using insecure HTTP for anything that requires authentication.
> "Bothering" with client-side password hashing, in the absence of TLS, is security theater.
Filtering out unsophisticated attackers I would not classify as "theater".
Read this, and let me know if the implications of port forwarding your server (or putting it on IP6) is readily apparent:
https://jellyfin.org/docs/general/post-install/networking/#s...
A lot of these users are not very sophisticated themselves. The least sophisticated attackers are likely to be the most numerous.
This is bad. People who say it's not bad (or worse, suggesting anyone dumb enough to publicly expose their server without TLS) are engaging in security snobbery.
Yes, TLS should be considered a given. Set things up right and you can use TLS locally, too, with Let's Encrypt, which is a prereq to stream some things to streaming sticks using Jellyfin's raw HTTP streaming without a Jellyfin client.
For whatever reason people here and on Reddit will tell you that you need to have Jellyfin pass through five VPNs, otherwise nasty things will happen. Meanwhile the actual devs suggests simply setting up a reverse proxy, which you can do in two lines with Caddy: https://jellyfin.org/docs/general/post-install/networking/re...
Reverse proxy itself will do barely any defense, what you need in combination is an authgate (authentik, authelia), and here we are moving from "simple reverse proxy" to fun weekend activity and then some getting it to work as expected. + it kills the app auth flow, so only web interface is suitable for this.
You can use a reverse proxy and still have working app auth, I have set this up via Authelia with the OIDC Jellyfin plugin.
However:
- This is EVEN MORE complex than "just" a reverse proxy.
- I'm not really sure it wins much security, because...
- at least I'm not relying on Jellyfin's built-in auth but I'm now relying on its/the plugin's OIDC implementation to not be completely broken.
- attackers can still access unauthenticated endpoints.
Overall I really wish I could just do dumb proxy auth which would solve all these issues. But I dunno how that would work with authing from random clients like Wii (and more importantly for me, WebOS).
> Reverse proxy itself will do barely any defense, what you need in combination is an authgate
What’s your threat model?
Same as anyones: random bots scanning IP/ports to find established services and trying exploits from the book.
With a reverse proxy, I don't see how this would work. The whole way the reverse proxy works is you use a subdomain name ("jellyfin.yourdomain.org") to access Jellyfin, rather than some other service on your server. The reverse proxy sees the subdomain name that was used in the HTTP request, and routes the traffic based on that. Scanning only the IP address and port won't get attackers to Jellyfin; they need to know the subdomain name as well.
The only tricky part here would be to make sure you’re doing a wildcard certificate, so that your subdomain doesn’t appear in Certificate Transparency logs.
true, but I kinda dont want hiding from plain sight to be my only line of defence.
If you expose Jellyfin on 443, have HTTPS properly set up (which Caddy handles automatically), your admin password is not pswd1234 (or you straight up disable remote admin logins), and use a cheap .com domain rather than your IP--what is the actual attack surface in that case?
As far as I can remember that is more or less what is usually suggested by Jellyfin's devs, and I have yet to see something that convinces me about its inadequacy.
He claims there are known exploits. Though I also want to know if this is really true.
The absolute worst thing I can see in there is that an third party who somehow managed to get a link to one of your library items (either directly from you or from one of your users--or by spending the next decade bruteforcing it I guess) could stream said item: https://github.com/jellyfin/jellyfin/issues/5415#issuecommen...
Everything else looks to me like unimportant issues, that would provide someone who's already logged in as a user minor details about your server.
Nearly everyone uses the *arr stack with the Trash guides.
Which means that the paths are pretty damn uniform.
Unless I am misunderstanding the discussion on GitHub, the attacker would still need to know the exact path where the file is saved, and the name of the file itself. Even then, all they can do is download the file from your device--which they could just torrent themselves for a fraction of the effort.
A DDoS is still a valid attack.
Very few consumer connections can manage, say, 100 clients downloading a massive video file simultaneously.
Yea its pretty bad, there are pages of non-fixed confirmed exploits, you really shouldnt let it face the net.
VPN is one solution, and actually the only real solution for app-based jellyfin (TV, phone apps) I found so far.
Another is to host Jellyfin behind reverse proxy, and have a completely independent authgatein front of it (authentik, authelia). Jellyfin even supports LDAP (trough plugin), so you dont have to login twice per visit. The downside is only web interface can be hidden this way, as apps will break expecting jellyfin auth page and finding something else.
To alleviate your concerns, I have a public facing Jellyfin instance hosted on a subdomain for almost a year now. So far zero pwns or bot activity.
It’s still a mess and any suggestions to fix it are met with hostility which is a shame because I’d love to use it. Last I checked there were still endpoints not behind auth that exposed stuff you’d probably not want exposed.
I run it in a docker container behind traefik in another container. Getting that wired up and working in podman was quite the challenge. Docker container mounts my media as read only.
i didn't have much trouble
services:
jellyfin:
build:
dockerfile: jellyfin.Dockerfile
container_name: jellyfin
group_add:
- 44
- 993
environment:
- TZ=<redacted>
- JELLYFIN_PublishedServerUrl=<redacted>
- DOMAIN_NAME=<redacted>
ports:
- 8096:8096
- 8920:8920
- "7359:7359/udp"
volumes:
- ./config:/config
- ./cache:/cache
- ./config/index.html:/jellyfin/jellyfin-web/index.html
- type: bind
source: /mnt/storage/Video
target: /media
restart: always
devices:
- /dev/dri:/dev/dri
i also recommend seerr to pair with jellyfin: https://seerr.dev/
my wife logs into the seerr ui with her jellyfin account, makes requests, they get grabbed by sonarr/radarr, which in turn place them in the correct library, and they're identified & labeled correctly on import