How would you expose Jellyfin securely without a vpn?
Assuming the user will not be connecting over vpn, but is both remote and non-technical, how would you expose Jellyfin to them securely?
204
Comments201View original on discuss.online
Assuming the user will not be connecting over vpn, but is both remote and non-technical, how would you expose Jellyfin to them securely?
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 hesitating 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/
Reverse proxy with auth in front of the actual jellyfin login. Like pangolin.
How do you get apps through something like that? Do you have to open your browser and hit the URL periodically to handle auth there and it just remembers your IP?
You can set pangolin to allow access to an entire resource or just certain paths without the front auth, instead relying on the built in auth.
Your random plex/emby/jellyfin server isn't going to be a huge target and the built in auth is good enough for the limited access your media system should have.
Wait so if you're gonna allow access without authentication then why bother putting pangolin in front of jellyfin? Does it help in some other kind of way? I don't really get how it helps without interfering with apps accessing jellyfin.
I am really not comfortable with that. Limited or not.
If there was a Jellyfin app that supported adding a custom header to the server connection, you could set your reverse proxy to just let the connections with that secret key header through, and make everything else go through the extra auth middleware. But as far as I know, none of the Jellyfin apps have that feature, even though it has been requested. Lots of other selfhosted apps do have the feature though, and I use it in a few places as well.
Gotcha yeah, I did this for LunaSea with traefik forward auth for the arrs, but the lack of support in jellyfin clients is annoying. Though personally I've been waiting 5 years for Findroid to support transcoded streams / adjusting video quality so personally that's higher on my list of priorities.
You don't.
Gotcha I see, just checking if I missed something since that was the issue last time I tried doing something like that. These days I just yolo it and expose jellyfin to the public Internet.
i might have spoken to soon.
https://www.reddit.com/r/PangolinReverseProxy/comments/1ouk4u6/phone_app_access/
i havent tried it though, but sounds interesting.
Would you need to? Are apps a viable vector in? Basic auth in front of web ui does make sense though.
What do you mean viable? The web UI is just an app that is delivered to your browser, it makes more or less the same API requests as an app would make, so IDK why the risk would be lower with an app?
If an attacker can access the login endpoint for example to brute force or dictionary attack, it doesn't matter if the web UI is or isn't accessible if the login endpoint it uses is exposed for an app. The attacker could serve their own copy of the web UI and proxy requests to the API your app connects to. Blocking the html from being served doesn't make a difference.
Okay then use a vpn.
That's exactly the point I'm getting at. Putting an auth wall doesn't work with many apps, and if you add exceptions to the API then you're not really protecting anything.
@BakedCatboy @anon_8675309
I think that could be fixed with authentication through headers (netbird reverse proxy supports that, no idea about pangolin though) but apps should also support adding custom headers on requests
Yes that's what I would like to advocate for. I did something similar with LunaSea, but often people suggest doing that with Jellyfin and are not aware that almost no apps support it, and that adding exceptions for the API makes you basically as secure as not having it. But people tend to get very defensive when you try to tell them that something won't work, so I try to phrase it as a question to see if I can get them to understand what the limitations are in a way that's less confrontational.
Possibly mTLS, which you'd configure in your reverse proxy. You could email them the certificate and instructions on installing it. I believe for Chromium browsers on Windows you basically just double click the cert and click through the wizard. Firefox I know has a thing in the settings for importing the cert. Android you just tap on the cert and make sure it opens with 'Certificate Installer' if it gives you the option.
I recently did exactly this. Only works with the web UI, no apps support it, but working well and those without the cert just get a 400 error. Not sure if non technical tbh, since you will get warnings when adding your root certificates to any device, and that might scare some who don't understand what it does.
Also set it up through wireguard, so can punch out of double NAT.
Yeah that's true.
It's not a root certificate, and I've never seen any warnings.
You need the web site to use a certificate from the same root authority as your client certificate. Otherwise browsers won't present the certificate to the server. That means either warnings on connect or adding the root cert.
I do think if you are doing it with them in person it is doable to add it.
I'm not sure if I've misunderstood you, but I use Lets Encrypt for the server's TLS, and then my own CA cert (which is only present on the webserver) for the client's mTLS and everything works fine, since it's the client that validates the server's cert and the server that validates the client's cert.
This should be at the top
Not a terrible idea but im not sure rokus or fire sticks or whatever even have this capability.
Yeah, good to do for web ui, but none of my friends and family ever use the web ui. They are all on TVs. VPNs are probably easier to setup than mTLS if you're having people use their computers.
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
https://github.com/jellyfin/jellyfin/issues/5415#issuecomment-2825240290
It really seems overblown of an issue...
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.
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.
Reminds me of
https://everyuuid.com/
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.
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.
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.
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.
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
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?
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:
Cons:
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.
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.
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.
This is solid. I wonder if you could rig up a ddns somehow to keep it seamless?
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.
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?
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".
What's your concern about running it behind a reverse proxy, like caddy or nginx?
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
https://www.androidpolice.com/lastpass-breach-plex-update/
https://www.moanmyip.com/
It's exactly what it sounds like.
I like how if it’s IPv6 it just gives up
if 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
That’s basically the VPN solution but with a little more flexibility.
If you want to actually expose the service, you can use Tailscale to connect it to a VPS and then expose that port to the web with Nginx, but if you do that, be prepared on the security front because…you know…open internet be full of hazards.
“If you don’t want to use a VPN, use a VPN instead”
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.
https://caddyserver.com/docs/caddyfile/directives/basic_auth
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.
That said, VPN would be much more manageable if I was trying to really push performance or scale out the network.
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.
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.
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.
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.
call me crazy but I just use a couldflare tunnel since my domain is already provided through them. They make it really easy to add sub-domains attached to specific ports on the local machine and automatically adds the proper DNS entries. Additionally they have a ton of domain security/anti-bot measures you can set up.
https://community.cloudflare.com/t/using-cloudflare-for-remote-access-to-jellyfin/855051
I haven't heard of anyone being kicked off.
I haven't had any issues like that. It's been pretty plug and play and I have it set up for some family that are accessing it from out of town. No problems except for the big cloudflare outage that happened a while ago.
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
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. 🙃
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.
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. 😀
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.
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. :)
And just looked them up, saw their $2 a month VPS has a 3TB bandwidth limit and I signed up immediately lol.
Thank you!
Thank you! I haven't heard of racknerd/low end box, I'll have to check them out. Yeah I'm not worried about the CPU just the bandwidth haha.
I have 30 people on my Plex share and never had to care about bandwidth so I'm a bit worried for my end
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.
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".
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.
Sorry but are you guy not using Linux as your servers? Windows? Now I understand.
Did you just suggest Linux has no vulnerabilities in any of its distros, and neither does any of the self-hosted services?
Not at all, there's legal risk if you're hosting your blurays. Cloudflare even explicitly forbids such use. VPN or nothing imo.
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.
Not sure about that, I think it's more just that they don't want people streaming terabytes of traffic through their edge.
Well, I don't know. Cloudflare seems to be the standard, again with that one exception, and the only reason PTB has a different situation is because the founders had a connect.
They have to be. They have to at least somewhat comply with laws to avoid lawsuits and fines
Oh, ok, "they have to be" in the same way my seedbox says not to download copyright material. Got it.
Legal risk of bluray rips, as opposed to other media types?
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
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.
https://tailscale.com/docs/features/containers/docker/how-to/connect-docker-container
If they could be using web UI (I'm not sure how a client would work with auth like that) then it kind of depends on how much hassle they can live with and how secure you want to be
Simplest would be to use https://doc.traefik.io/traefik/reference/routing-configuration/http/middlewares/basicauth/
You set up username and password and share those with the user. But it can be brute-forced
Something more secure but also a bit more demanding would be some kind of email otp
https://docs.goauthentik.io/add-secure-apps/flows-stages/stages/authenticator_email/
Set up authentik to send time-limited link to their email that well let them through. But they would have to authenticate every time they access
Why no VPN?
Yeah, let me just walk my normie friends and parents through setting up a VPN on their TV so they can stream their shows.
Sounds annoying but doable. No need to be offended I'm just asking why VPN is being ruled out.
I stuck a rPi in their houses that runs pihole+nginx+tailscale. As far as they're concerned they go to https://jellyfin.example.domain/ and they're there.
Better yet, they go to http://homarr.notlocal/ and they have nice little icons to click on, that take them to all the front-end services I run.
They get pihole goodness for free. Their homepage is attached to their pihole if they want to pause/stop it.
I'd like to set them up to be more declarative than I have, setup/updating is a pain. Nix is interesting but the learning curve is too steep for the effort I'm willing to put in. As per usual, being lazy will end up being more work for me in the long run.
VPNs are not trivial to use for normies.
Way easier than reverse proxies IMO
They mean on the client side most likely. A reverse proxy will be transparent to the user.
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.
Ports are closed by firewalls, and if you need to port forward on your home router this is a non-issue anyway
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.
Some reverse proxies have an authentication layer.
But this typically breaks the jellyfin Mobile app.
Cf used to have it against the rules, but it's fine now.
edit: you can in fact do video, but they have added lines about ~piracy
Ah cool, didn't know!
Just re-read to make sure, they def changes the non-html to allow it, but they do def have non-pirate terms in there
end to end encryption with your own key on their tunnel might be a good idea (which is allowed)
😬
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
16 acronyms in this thread; the most compressed thread commented on today has 14 acronyms.
[Thread #311 for this comm, first seen 23rd May 2026, 22:30] [FAQ] [Full list] [Contact] [Source code]
Good bot.
Reverse proxy with fail2ban or crowdsec. It's possible to set up things like Pangolin which ultimately use a VPN between external and internal access points but not at the client, though it takes more setup if you want to use apps over pangolin instead of just the browser.
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.
@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.
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.
If client certificates and basic auth is not supported by jellyfin:
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
I'm no expert, but an unguessible URL path is similar but not visible to DNS. Could do both.
Just stumbled upon this: https://jellyfin.org/docs/general/post-install/networking/
Base URL
Running Jellyfin with a path (e.g. https://example.com/jellyfin) is supported.
caution Base URL is known to break HDHomeRun, the DLNA plugin, Sonarr, Radarr, and MrMC.
so: yes, it works. but most likely: no you don't want this.
If jellyfin Clients can do URLs, sure
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
Could always get super complicated and rotate your port knocking so no replay attacks. But now we're just getting silly :)
As others have mentioned, a reverse proxy, like nginx or caddy. These are web servers, so you need to configure it or an app that runs in it. May I shill: Nginx Proxy Manager (NPM).
My use cases are:
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.
How much access do you have to their system? I would set up a script on their end to poll https://ipv4.icanhazip.com/ and send you their IP. I would then trigger a firewall rule change on your end to that information. This keeps the access to only their IP, with maybe a few minutes between polls where it might be different.
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.Plugin is archived and will become outdated (and unsafe to use) over time. Don't use it.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.
*Archived, arrived just means it is here
You don't say. My autocorrect had a mind of its own again. Fixed it.
If that is the same as oAuth, that can be done with a plugin.
But yes, that's not native.
Tailscale or cloudflare
Also running all your pirated content traffic through the works biggest internet traffic/service provider is certainly a choice lol
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
Ask them to use the Jellyfin web, and you expose it to the public via Netbird / Pangolin locked behind SSO
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.
Cloudflare. Just make sure to disable caching
How do you get the mobile app to connect?
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
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
What are you afraid of?
My jellyfin runs in a a rootless podman container
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)
Then don't expose anything on the internet
Adding onto the other comments, if you have admin access to your network router/firewall you can configure the incoming port forward itself to only allow specific IP addresses while dropping traffic from any other internet WAN IPs. It's a bit like using the Jellyfin whitelist/blacklist but doing it at the network level. This drops all unwanted internet traffic to that port at the firewall before ever reaching the Jellyfin software. Downside is having to occasionally update the firewall whenever there are IP address changes.
This is probably only feasible if you only have some specific Jellyfin clients in mind to accept connections from, not any random person from any random WAN IP address.
This is a terrible idea, as you’re trusting their network and device security blindly.
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.
you don't.
if you're intent on "spreading your legs" to the world, get a WAF.
edit: don't get mad about the analogy, it's apt.
when you open your local network to public access without protection, you're bound to have a couple "accidents" and "infections".
protect your local network with at least a proper firewall and segmented network.
a properly configured WAF is better than any reverse proxy you could use.
Tailscale
"without a VPN"
My bad, sometimes I forget that Tailscale is nothing but wireguard VPN.
headscale + tailscale. U will need a very small vps for headscale though.
That is a VPN.
Yup. I got so wrapped up in "I need to provide this solution" I forgot to think about terminology.
Meh. If someone hacks my server and watches TV then idc, have at it. They earned it
EDIT: the downvotes are warranted but they change nothing
Sure... If someone managed to stream some of my media... They probably earned it... But then they exploit a vulnerability to perform arbitrary code execution, and leverage that to hack everything else on my network...
https://app.opencve.io/cve/CVE-2023-30626
I'm learning a lot of this as I go and have not exposed any services to the internet yet, but would VLANs not contain the damage to a limited portion of the network? Because that's the plan I'm working toward. Not just for Jellyfin but a handful of other services.
That… might work. Do you have a different physical server for each service though?
The issue is once someone is in, then they can try to jailbreak and move laterally to get to other things. Other devices, into the file system.
Jellyfin might not be your concern, but are there other files on that server? Or services? Secrets passwords etc? If anything else is on that vlan, what security flaws might be there that an attacker could use?
There is no personal information on anything in that proposed VLAN currently, and in the future, the most personal stuff it will include is a chat program to replace Discord. In all, I'm assuming I can run the reverse proxy and most services (not even a dozen) on a mini PC, and then somewhere between 1-4 on a NAS. Two devices total on this VLAN, unless I learn of something that would change this plan.
If Jellyfin gets compromised, you risk everything else on the same server getting compromised, as well as everything that server can reach.
VLANs can certainly reduce what is at risk, but wouldn't the machine running the Jellyfin client be reachable from the Jellyfin server? And if they manage to move laterally to the client machine, what could they then reach from there?
Again, still learning, but my understanding is that that's what VLAN rules can protect against.
That depends a lot on what you do with them...
VLANs work on a layer where devices can either reach each other or they cannot.
Let's say you have your main desktop computer in the "main" VLAN, and your Jellyfin server in the "jellyfin" VLAN, and a third server for your home-assistant in the "home-assistant" VLAN, and finally some IOT devices in the "iot" VLAN.
You connect the VLANs as follows:
Remember that all connected VLANs much be bidirectional.
Now someone compromises your Jellyfin. They now control and has access to everything on the Jellyfin server, but they also have network reachability to your main computer, because your "main" and "home-assistant" VLANs are connected. They can now try to exploit your main computer.
If they are successful in exploiting your main computer, then they can use your main computer to jump to the home-assistant server because again, these two VLANs are connected. And you likely have the credentials for accessing home-assistant available on your main computer somewhere.
Now they are on your home-assistant server, and they can now start trying to exploit your IOT devices.
If VLANs are connected, they don't care which direction the traffic flows.
If you want to control traffic flow directions you need a firewall. A firewall can sit between VLANs and block traffic coming from one to other, but not the other to the one.
Remote code execution is a concern. Your server and your network as a whole (including other VLANs) are susceptible to attack if Jellyfin is compromised. If Jellyfin is running on the host, it would be trivial to hack your server (and anything else running/connected to it). If Jellyfin is in a Docker/Podman containers, it doesnt prevent attacks against the host (sandbox escape, kernel privilege escalation, etc), or against your network over some ports. Even if the server is on it's own VLAN, a vulnerability or weakness in your router could still lead to a compromise, meaning that any devices that is in any way connected to your router (including personal devices) could be attacked.
There is a lot of depth to this topic of course. And at some point you just calculate your risks and weigh your options. There is no such thing as perfect security of course.
Didn't down vote, and I get what you're saying to a certain extent. I'm not touting my server as hack-proof in the least, but it would take some work. My concern wouldn't be someone hacking in and listening to my personal music collection I've been working on for decades...it goes all the way back to 1937.
I would be more concerned that my compromised server was used as a zombie attack on some other server. The first VPS server got ransacked and used over-nite to (unsuccessfully) DDoS another business site.I got a ton of nasty grams for that boner. I didn't loose anything but time.
Bitcoin miners are easy to spot. I've never really understood why someone would hack into a small server and deploy a nefarious miner. On a huge corporate server farm, sure. But not some small selfhost VPS somebody found on lowendbox.
Because they're not mining on just one, they're mining on thousands.
I understand economy of scale, but how much could you actually mine over nite on a little droplet before junior sysadmin notices that there is an influx of nasty grams in his in box and his little 4 banger VPS is maxed out on resources.
Long enough to make it worth it. Most people aren't paying that much attention.