Assuming the user will not be connecting over vpn, but is both remote and non-technical, how would you expose Jellyfin to them securely?
You must log in or # to comment.
I toyed with the idea of exposing ports and decided against it. I don’t understand networking well enough yet. For me specifically, VPN access has been perfectly workable in the US with both speed and ease of access.
Can you use fail2ban on Jellyfin? That might be a wise step.
I use a Wireguard tunnel to a VPS and fail2ban with geoblocking: https://codeberg.org/skjalli/jellyfin-vps-setup
See if there are any apps that will handle the VPN tunneling transparently, then provide the web interface, all in one.
If you can’t find any that work like you want, I would put an authenticating reverse proxy in front of jellyfin. But last time I tried that, it only half worked. I don’t know if that’s changed.
Worst case, a reverse proxy that only exposes the necessary endpoints. Or a WAF that can block known attacks.
In any case, you should have a firewall rule as narrow as possible to only limit access to them. Static IP address if possible, then subnet, then ASN. Whatever is the most restrictive but still works.
I agree with reverse proxy + middleware. I’d also suggest something like Jellyswarm as the front end. That way I can connect to other friends’ servers too.
Tailscale
“without a VPN”
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.
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.
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
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.
Probably the only way to guarantee nobody can probe your media and stream it without authentication is to make sure to rename everything using a format that only you use or mount all your media under a path inside docker that contains a long randomly generated folder prefix.
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.
Reminds me of
It really seems overblown of an issue…
afaik but I’m not sure, Jellyfin lacks support for OIDC AuthN which is a clear sign that you cannot expose this publicly.
There’s a plugin for that.
says repo is archived
Oops. I tried it in the past and just linked to quickly without taking a close look at the repo. I’ve updated the above posting. Thanks for pointing this out.
Plugin is arrived
*Archived, arrived just means it is here
You don’t say. My autocorrect had a mind of its own again. Fixed it.
Perhaps (and I know I might be weird) running pangolin on something like hetzner? (Which I do)
This is the way I do it with services. Has auth. Rules for access per service. Handles reverse proxy. And can integrate crowdsec. Not a security guru…
Pangolin?
Pangolin reverse proxy https://github.com/fosrl/pangolin
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
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
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.
Not at all, there’s legal risk if you’re hosting your blurays. Cloudflare even explicitly forbids such use. VPN or nothing imo.
Legal risk of bluray rips, as opposed to other media types?
Wow, Cloudflare is against piracy? Every single site I’ve ever seen in my life is registered with Cloudflare and uses their DNS with the exception of PTB I believe.
They have to be. They have to at least somrwhat comply with laws to avoid lawsuits and fines
Not sure about that, I think it’s more just that they don’t want people streaming terabytes of traffic through their edge.
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.
Just read their actual documentation. You’ll want to either way.
Set up a reverse proxy with https always on. And get a good (physical) firewall, preferably something akin to opnsense, pfsense, openwrt. Exposing is always a risk, and if you do want it, you have to bear the responsibility for your own security. Keep things up to date, set up monitoring and a good logging system (Wazuh) comes to mind.
Exposure means a security risk. How you deal with that security risk is your choice.
Cloudflare and the likes forbid usage of their stuff for these things.
How does a reverse proxy helps for security? I mean, the problem here is that exposing Jellyfin on the internet is dangerous: the only way to improve security via a reverse proxy would be mTLS, but I’m not sure how it would work client side.
By setting up a reverse proxy you redirect the traffic through that specific proxy which means less open ports (basically just 80/443), less monitoring, the ability to easily put a WAF inbetween, etc.
You’ve got a couple benefits. If you have a domain name, and aren’t advertising it publicly, then you can use the reverse proxy to point that domain to a non-standard port that Jellyfin runs on.
Security through obscurity is not good security, but it does prevent the majority of port scanning attacks. You can also use fail2ban on the reverse proxy side to try and mitigate some attacks.
Cloudflare and the likes forbid usage of their stuff for these things.
😬
Cf used to have it against the rules, but it’s fine now.
Ah cool, didn’t know!
Does Tailscale count as a VPN for you? It’s how I roll. Well, I run my own headscale server, but the free Tailscale tier is going to be fine for any reasonably sized personal project.
Tailscale is a vpn for all that matters.
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/
