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 register to comment.
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.
Removed by mod
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.
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.
Meh. If someone hacks my server and watches TV then idc, have at it. They earned it
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…
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:
- “main” can reach the Internet, but you also want to access your jellyfin and home-assistant, so you connect it to those two VLANs (“jellyfin” and “home-assistant”)
- “Jellyfin” can reach the Internet (because you want updates), but Jellyfin doesn’t need to reach anything else on your local network… However since you already connected “main”, then “jellyfin” can reach it.
- “home-assistant” needs to reach the Internet, but also the “iot” VLAN where some of the devices it controls resides. You also already connected “main” because you wanted to access home-assistant from your computer.
- “iot” is blocked from reaching the internet, and it’s only connected to the “home-assistant” VLAN because home-assistant needs to reach it.
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.
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.
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.
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?
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.
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.
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.
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 requestsYes 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.
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.
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.
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.
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.
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.
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.
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.
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).
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?
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?
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.
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”.
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.
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.
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.
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.
