What’s your go too (secure) method for casting over the internet with a Jellyfin server.
I’m wondering what to use and I’m pretty beginner at this
You must log in or register to comment.
I don’t use jellyfin but my general approach is either:
- Expose it over a VPN only. I usually use Tailscale for this so that I can expose individual machines but you do you
- Cloudflare tunnel that exposes a single port on a single internal machine to a subdomain I own
There are obviously ways to do this all on your own but… if you are asking this question you probably want to use one of those to roll it. Because you can leave yourself ridiculously vulnerable if you do it yourself.
That’s my feeling too
I would look into Tailscale based on your responses here. I don’t know what your use case is exactly but you set TS up on your server and then again on your phone/laptop and you can connect them through the vpn directly. No extra exposed ports or making a domain or whatnot.
If you want other people to access the server they will need to make a TS account and you can authorize them.
I keep jellyfin up to date in a container and forward tcp/8920 on my router to the container. Easy and plenty secure. People in this thread are wildly overthinking it.
Cloudflare. No public exposure to the internet.
Are we not worried about their terms of service? I’ve been using pangolin
We are, Batman, we are.
I VPN to my network for it.
I expose jellyfin and keycloak to the internet with pangolin, jellyfin user only has read access. Using the sso 🔌 jellyfin listens to my keycloak which has Google as an identity provider(admin disabled), restricting access to my users, but letting people use their google identity. Learned my family doesn’t use anything that isn’t sso head-to-toe.
It’s what we do in the shadows that makes us heroes, kalpol.
First time I hear someone using keycloak for local hosting.
I run multiple enterprise companies through it who are transferring significantly more sensitive data than me. I’m not as strict as some people here, so no, I don’t really care. I think it’s the best service, especially for free, so until things change, that’s what I’m using.
“Technically” my jellyfin is exposed to the internet however, I have Fail2Ban setup blocking every public IP and only whitelisting IP’s that I’ve verified.
I use GeoBlock for the services I want exposed to the internet however, I should also setup Authelia or something along those lines for further verification.
Reverse proxy is Traefik.
Wireguard vpn into my home router. Works on android so fire sticks etc can run the client.
If you’re a beginner and you’re looking for the most secure way with least amount of effort, just VPN into your home network using something like WireGuard, or use an off the shelf mesh vpn like Tailscale to connect directly to your JF server. You can give access to your VPN to other people to use. Tailscale would be the easiest to do this with, but if you want to go full self-hosted you can do it with WireGuard if you’re willing to put in a little extra leg work.
What I’ve done in the past is run a reverse proxy on a cloud VPS and tunnel that to the JF server. The cloud VPS acts as a reverse proxy and a web application firewall which blocks common exploits, failed connection attempts etc. you can take it one step beyond that if you want people to authenticate BEFORE they reach your server by using an oauth provider and whatever forward Auth your reverse proxy software supports.
I’m using a cheap VPS that connects over Tailscale to my home server. The VPS runs Nginx Proxy Manager, has a firewall and the provider offers DDOS protection and that’s it.
I’m using jf on unraid. I’m allowing remote https only access with Nginx Proxy Manager in a docker container.
I see everyone in this thread recommending a VPN or reverse proxy for accessing Jellyfin from outside the LAN. While I generally agree, I don’t see a realistic risk in exposing Jellyfin directly to the internet. It supports HTTPS and certificates nowadays, so there’s no need for outside SSL termination anymore.
In my setup, which I’ve been running for some time, I’ve port-forwarded only Jellyfin’s HTTPS port to eliminate the possibility of someone ending up on pure HTTP and sending credentials unencrypted. I’ve also changed the default Jellyfin’s default port to a non-standard one to avoid basic port-scanning bots spamming login attempts. I fully understand that this falls into the security through obscurity category, but no harm in it either.
Anyone wanna yell at me for being an idiot and doing everything wrong? I’m genuinely curious, as the sentiment online seems to be that at least a reverse proxy is almost mandatory for this kind of setup, and I’m not entirely sure why.
You remember when LastPass had a massive leak and it out of their production source code which demonstrated that their encryption security was horrible? That was a Plex vulnerability. All it takes is a zero day and one of the packages they’re using and you’re a prime target for ransomware.
You can see from the number of unauthenticated processes in their security backlog that security really has been an afterthought.
Unless you’re running in a non-privileged container with read only media, I definitely would not put that out on the open network.
Jellyfin has a whole host of unresolved and unmitigated security vulnerabilities that make exposing it to the internet. A pretty poor choice.
And which one of those are actually vulnerabilities that are exploitable? First, yes ofc unauthenticated endpoints should be fixed, but with those there is no real damage to be done.
If you know the media path then you can request a playback, and if you get the user ids then you can get all users. That’s more or less it.
Good? No. But far from making it a poor choice exposing it.
These are all holes in the Swiss cheese model.
Just because you and I cannot immediately consider ways of exploiting these vulnerabilities doesn’t mean they don’t exist or are not already in use (Including other endpoints of vulnerabilities not listed)
This is one of the biggest mindset gaps that exist in technology, which tends to result in a whole internet filled with exploitable services and devices. Which are more often than not used as proxies for crime or traffic, and not directly exploited.
Meaning that unless you have incredibly robust network traffic analysis, you won’t notice a thing.
There are so many sonarr and similar instances out there with minor vulnerabilities being exploited in the wild because of the same"Well, what can someone do with these vulnerabilities anyways" mindset. Turns out all it takes is a common deployment misconfiguration in several seedbox providers to turn it into an RCE, which wouldn’t have been possible if the vulnerability was patched.
Which is just holes in the swiss cheese model lining up. Something as simple as allowing an admin user access to their own password when they are logged in enables an entirely separate class of attacks. Excused because “If they’re already logged in, they know the password”. Well, not of there’s another vulnerability with authentication…
See how that works?
The issue is not encryption, it’s the unauthenticated API. People can interact with your server without an account.
Specifically these issues: https://github.com/jellyfin/jellyfin/issues/5415
The big one is that video/audio playing endpoints can be used without authentication. However, you have to guess a UUID. If Jellyfin is using UUIDv4 (fully random), then this shouldn’t be an issue; the search space is too big. However, many of the other types of UUIDs could hypothetically be enumerated through brute force. I’m not sure what Jellyfin uses for UUIDs.
It’s difficult to say exactly what all a reverse proxy adds to the security conversation for a handful of reasons, so I won’t touch on that, but the realistic risk of exposing your jellyfin instance to the internet is about the same as handing your jellyfin api over to every stranger globally without giving them your user account or password and letting them do whatever they’d like for as long as they’d like. This means any undiscovered or unintentional vulnerability in the api implementation could easily allow for security bypass or full rce (remote code execution, real examples of this can be found by looking at the history of WordPress), but by siloing it behind a vpn you’re far far far more secure because the internet at large cannot access the apis even if there is a known vulnerability. I’m not saying exposing jellyfin to the raw web is so risky it shouldn’t be done, but don’t buy into the misconception that it’s even nearly as secure as running a vpn. They’re entirely different classes of security posture and it should be acknowledged that if you don’t have actual use for internet level access to jellyfin (external users, etc, etc) a vpn like tailscale or zero tier is 100% best practice.
Anyone wanna yell at me for being an idiot and doing everything wrong?
Not yell, but: Jellyfin is dropping HTTPS support with a future update so you might want to read up on reverse proxies before then.
Additionally, you might want to check if Shodan has your Jellyfin instance listed: https://www.shodan.io/
Jellyfin is dropping HTTPS support with a future update[…]
What’s the source for this? I wasn’t able to find anything with a quick google search
Upgrade notes for 10.11 RCs
I think the reason why its generally suggested to use a VPN is because it reduces the risk of intrusion to almost zero. Folks that are not network/sys admin savy would feel safer with the lowest risk solution. Using the port forward method, there could be configuration mistakes made which would unintentionally expose a different service or parts of their home network they don’t want exposed. And then there’s the possibility of application vulnerabilities which is less of an issue when only VPN users can access the application. That being said, I do expose some services via port forwarding but that’s only because I’m comfortable with ensuring its secure.
Reverse proxy is really useful when you have more than one service to expose to the internet because you only have to expose one port. It also automates the certificate creation & simplifies firewall rules inside the home network
Nah, setting non-standard ports is sound advice in security circles.
People misunderstand the “no security through obscurity” phrase. If you build security as a chain, where the chain is only as good as the weakest link, then it’s bad. But if you build security in layers, like a castle, then it can only help. It’s OK for a layer to be weak when there are other layers behind it.
Even better, non-standard ports will make 99% of threats go away. They automate scans that are just looking for anything they can break. If they don’t see the open ports, they move on. Won’t stop a determined attacker, of course, but that’s what other layers are for.
As long as there’s real security otherwise (TLS, good passwords, etc), it’s fine.
If anyone says “that’s a false sense of security”, ignore them. They’ve replaced thinking with a cliche.
People misunderstand the “no security through obscurity” phrase. If you build security as a chain, where the chain is only as good as the weakest link, then it’s bad. But if you build security in layers, like a castle, then it can only help. It’s OK for a layer to be weak when there are other layers behind it.
And this is what should be sung from the hills and mountaintops. There’s some old infosec advice that you should have two or three honeypots, buried successively deeper behind your security, and only start to worry when the second or third gets hit; The first one getting hit simply means they’re sniffing around with automated port scanners and bots. They’re just throwing common vulnerabilities at the wall to see if any of them stick. The first one is usually enough for them to go “ah shit I guess I hit a honeypot. They must be looking for me now. Never mind.” The second is when you know they’re actually targeting you specifically. And the third is when you need to start considering pulling plugs.
It feels like everything is a tradeoff and I think a setup like this reduces the complexity for people you share with.
If you added fail2ban along with alert email/notifications you could have a chance to react if you were ever targeted for a brute force attempt. Jellyfin docs talk about setting this up for anyone interested.
Blocking IP segments based on geography of countries you don’t expect connections from adds the cost of a VPN for malicious actors in those areas.
Giving Jellyfin its own VLAN on your network could help limit exposure to your other services and devices if you experience a 0day or are otherwise compromised.
Fail2ban isn’t going to help you when jellyfin has vulnerable endpoints that need no authentication at all.
Your comment got me looking through the jellyfin github issues. Are the bugs listed for unauthenticated endpoints what you’re referencing? It looks like the 7 open mention being able to view information about the jellyfin instance or view the media itself. But this is just what was commented as possible, there could be more possibilities especially if combined with other vulnerabilities.
Now realizing there are parts of Jellyfin that are known to be accessible without authentication, I’m thinking Fail2ban is going to do less but unless there are ways to do injection with the known bugs/a new 0day they will still need to brute force a password to be able to make changes. I’m curious if there is anything I’m overlooking.
unless there are ways to do injection with the known bugs/a new 0day
TBH, that should be enough right here. That is a JUICY target for hacking.
You can tell outside that someone is running JF.
You know what packages are used.
You have full access to the source.
You know what endpoints are exposed and available.
All you need is a whole in ffmpeg, a codec, a scaler, or something in libAV. There are a hundred different projects in there from everyone and their brother. And all somebody with experience needs is one of them to have an exploit in a spot where you can send it a payload through an endpoint that doesn’t require authentication.
We need something to gatekeep. Some form of firewall knocking, or VPN. We don’t need JF to be as publicly accessible as Netflix; we just need a way for our friends and family to get in, prove they’re who they are, and reject all anonymous traffic.
Reverse proxies can be useful for hiding your IP if you do something like host it in a VPS and tunnel the traffic back to your self hosted service. There’s also a lot of documentation on attaching things like fail2ban or crowd sec which can be helpful in reducing the threat from attacks. if you’re running lots of services it can reduce the risk of two apps using the same ports as ultimately everything will go through ports 80 and 443 on the public facing side. Finally again if you’re hosting several services having a central place to manage and deal with cert from can save a lot of time rather than having to wrangle it per service/ server.
Imo that’s perfectly fine and not idiotic if you have a static IP, no ISP blocked ports / don’t care about using alt ports, and don’t mind people who find your domain knowing your IP.
I did basically that when I had a fiber line but then I added a local haproxy in front to handle additional subdomains. I feel like people gravitate towards recommending that because it works regardless of the answers to the other questions, even their security tolerance if recommending access only over VPN.
I have CGNAT now so reverse proxy in the cloud is my only option, but at least I’m free to reconfigure my LAN or uproot everything and plant it on any other LAN and it’ll all be fine.
I don’t disagree, and I am one of the VPN advocates you mention. Generally there is no issue with exposing jellyfin via proxy to the internet.
The original question seemed to imply an over-secure solution so a lot of over-secure solutions exist. There is good cause to operate services, like jellyfin, via some permanent VPN.
I used to do all the things mentioned here. Now, I just use Wireguard. If a family member wants to use a service, they need Wireguard. If they don’t want to install it, they dont get the service.
I started my homelab with a couple exposed services, but frankly the security upkeep and networking headaches weren’t worth the effort when 99% of this server’s usage is at home anyway.
I’ve considered going the Pangolin route to expose a handful of things for family but even that’s just way too much effort for very little added value (plus moving my reverse proxy to a VPS doesn’t sound ideal in case the internet here goes down).
Getting 2 or 3 extra folks on to wireguard as necessary is just much easier.
Pangolin could be a solution
Came here to say this. I use wireguard and it simply works.
Wireguard.
and a local reverse proxy that can route through wireguard when you want to watch on a smart tv.
its not as complicated as it sounds, it’s just a wireguard client, and a reverse proxy like on the main server.
it can even be your laptop, without hdmi cables
How would you do this off network?
You can also use a router that can run wireguard/openvpn and have that run the tunnel back to home for you. I’ve got a portable GL-Inet router with OpenWRT that I use for this when I’m on the road
deleted by creator
lemm.ee :‘’'(
My go to secure method is just putting it behind Cloudflare so people can’t see my IP, same as every other service. Nobody is gonna bother wasting time hacking into your home server in the hopes that your media library isn’t shit, when they can just pirate any media they want to watch themselves with no effort.
Nobody is gonna bother wasting time hacking into your home server
They absolutely will lol. It’s happening to you right now in fact. It’s not to consume your media, it’s just a matter of course when you expose something to the internet publicly.
What a bunch of B’s. Sure your up gets probed it’s happening to every ipv4 address all the time. But that is not hacking.
Anything you expose to the internet publicly will be attacked, just about constantly. Brute force attempts, exploit attempts, the whole nine. It is a ubiquitous and fundamental truth I’m afraid. If you think it’s not happening to you, you just don’t know enough about what you’re doing to realize.
You can mitigate it, but you can’t stop it. There’s a reason you’ll hear terms like “attack surface” used when discussing this stuff. There’s no “if” factor when it comes to being attacked. If you have an attack surface, it is being attacked.
@EncryptKeeper That’s my experience. Zombied home computers are big business. The networks are thousands of computers. I had a hacker zombie my printer(!) maybe via an online fax connection and it/they then proceeded to attack everything else on my network. One older machine succumbed before I could lock everything down.
Yup, the sad reality is that you don’t need to worry about the attacks you expect; You need to worry about the ones you don’t know anything about. Honeypots exist specifically to alert you that something has been breached.
Couple questions here.
What is a honeypot? I’ve only heard it in terms of piracy.
Also, what steps can someone take to reinforce this attack layer? You have an infograph or something people can google search their way through?
A honeypot is something that is intentionally left available, to alert you when it gets hit. In practice, they’re just a tool to tell security specialists when they need to start worrying; They wouldn’t be used by the average user at all.
The goal is to build your security like layers, and ideally have all of your services behind the secure walls. Between these layers, you have honeypots. If someone gets through your first layer of security but hits the honeypot, you know someone is sniffing around, or maybe has an exploit for your outer layer that you need to research. If they get through the second layer and hit your second honeypot, you know that someone is specifically targeting you (instead of simply running automated scans) and you need to pay closer attention. Etc…
Reinforcing the attack layer comes in two main forms, which work in tandem: Strengthening the actual layer, and reducing attack vectors. The first is focused on using strong passwords, keeping systems up to date, running something like Fail2Ban for services that are exposed, etc… The goal is for each layer of security to be robust, to reduce the chances of a bot attack actually working. Bots will simply sniff around and automatically throw shit at the wall to see if anything sticks.
The second part is focused on identifying and mitigating attack vectors. Essentially reducing the amount of holes in the wall. It doesn’t matter how strong the wall is if it’s full of holes for your server’s various services. The goal is typically to have each layer be as solid as possible, and grant access to the layers below it. So for instance, running a VPN. The VPN gets you access to the network, without exposing services externally. In order to access your services, they need to get through the VPN first, making the VPN the primary attack vector. So you can focus on ensuring that the VPN is secure, instead of trying to spread your focus amongst a dozen different services. If it’s exposed to the open internet, it is a new potential attack vector; The strength of the wall doesn’t actually matter, if one of those services has an exploit that someone can use to get inside your network.
Home users really only need to worry about things like compromised services, but corporate security specialists also focus on things like someone talking their way past the receptionist and into the server room, USB sticks getting “lost” around the building and plugged into random machines by curious employees, etc… All of these are attack vectors, even if they’re not digital. If you have three or four layers of security in a corporate setting and your third or fourth honeypot gets hit, you potentially have some corporate spy wrist-deep in your server room.
For an easy example, imagine having a default password on a service, and then exposing it to the internet via port forwarding. It doesn’t matter how strong your firewall is anymore. The bot will simply sniff the service’s port, try the default credentials, and now it has control of that service.
The better way to do it would be to reduce your attack vectors at each layer; Require the VPN to access the network via a secure connection, then have a strong password on the service so it can’t easily be compromised.
No, people are probing it right now. But looking at the logs, nobody has ever made it through. And I run a pretty basic setup, just Cloudflare and Authelia hooking into an LDAP server, which powers Jellyfin. Somebody who invests a little more time than me is probably a lot safer. Tailscale is nice, but it’s overkill for most people, and the majority of setups I see posted here are secure enough to stop any random scanning that happens across them, if not dedicated attention.
No, they are actively trying to get in right now. If you have Authelia exposed they’re brute forcing it. They’re actively trying to exploit vulnerabilities that exist in whatever outwardly accessible software you’re exposing is, and in many cases also in software you’re not even using in scattershot fashion. Cloudflare is blocking a lot of the well known CVEs for sure, so you won’t see those hit your server logs. If you look at your Authelia logs you’ll see the login attempts though. If you connect via SSH you’ll see those in your server logs.
You’re mitigating it, sure. But they are absolutely 100% trying to get into your server right now, same as everyone else. There is no consideration to whether you are a self hosted or a Fortune 500 company.
No, they are actively trying to get in right now. If you have Authelia exposed they’re brute forcing it.
No, they aren’t. Just to be sure, I just checked it, and out of the over 2k requests made to the Authelia login page in the last 24 hours, none have made it to the login page itself. You don’t know jack shit about what’s going on in another persons network, so I’m not sure why you’re acting like some kind of expert.
Yes they are. The idea that they’re not would be a statistical wonder.
2k requests made to the Authelia login page in the last 24 hours
Are you logging into your Authelia login page 2k times a day? If not, I suspect that some (most) of those are malicious lol.
You don’t know jack shit about what’s going on in another persons network
It’s the internet, not your network. And I’m well aware of how the internet works. What you’re trying to argue here is like arguing that there’s no possible way that I know your part of the earth revolves around the sun. Unless you’re on a different internet from the rest of us, you’re subject to the same behavior. I mean I guess I didn’t ask if you were hosting your server in North Korea but since you’re posting here, I doubt it.
I’m not sure why you’re acting like some kind of expert
Well I am an expert with over a decade of experience in cybersecurity, but I’m not acting like an expert here, I’m acting like somebody with at least a rudimentary understanding of how these things work.
Yes they are. The idea that they’re not would be a statistical wonder.
Guess I’m a wonder then. I’ve always thought of myself as pretty wonderful, I’m glad to hear you agree.
Are you logging into your Authelia login page 2k times a day? If not, I suspect that some (most) of those are malicious lol.
That’s 2k requests made. None of them were served. Try to keep up.
Well I am an expert with over a decade of experience in cybersecurity, but I’m not acting like an expert here, I’m acting like somebody with at least a rudimentary understanding of how these things work.
Then I guess I should get a career in cybersecurity, because I obviously know more than someone with over a decade of supposed experience. If you were worth whatever your company is paying you in wages, you would know that a rule blocking connections from other countries, and also requiring the request for the login page come from one of the services on your domain, will block virtually all malicious attempts to access your services. Such a rule doesn’t work for a public site, but for a selfhosted setup it’s absolutely an easy option to reduce your bandwidth usage and make your setup far more secure.
a rule blocking connections from other countries, and also requiring the request for the login page come from one of the services on your domain, will block virtually all malicious attempts to access your services.
Whoa whoa whoa. What malicious attempts?
You just told me you were the statistical wonder that nobody is bothering attack?
That’s 2k requests made. None of them were served.
So those 2k requests were not you then? They were hostile actors attempting to gain unauthorized access to your services?
Well there we have it folks lmao
And this is the start of the longest crypto nerd fight I’ve seen on Lemmy. Well done, people!
Not so much a fight as an exercise in futility lol
Well, I might as well put a dog in the fight. I’m considering my final, actually secure deployment of nextcloud.
This discussion has convinced me that a vpn is the only answer.
And almost everyone says wireguard.K. Thats what I will build.
It’s not the only answer, but it’s the one that will get you the most secure with the least amount of effort.
Ya. I understand VPN. I do enterprise IT stuff. The things I build assume a secure environment. VPN is step one.
Nailing down a web server on the internet tho … there’s so many ways to attack. There’s so many things to secure. And its a bit complex to manage all that.
The nextcloud site covers hardening the server, but doesn’t even mention vpn.
I’ve been watching threads like this. I’m pretty convinced vpn is the answer.Yeah Nextcloud won’t mention VPN for hardening because the assumption is you want it publicly accessible.
I have a number of things publicly accessible and there are a number of things I do to secure them. crowdsec monitoring and blocking, a reverse proxy with OIDC for authentication, a WAF in front of it all. But those are only for the things I have exposed because I want other people to use them. If it’s something just for me, I don’t bother with all that and just access it via VPN.
Full guide to setting up Jellyfin with Reverse Proxy using Caddy and DuckDNS
I followed this video and modified some things like ports
I access it through a reverse proxy (nginx). I guess the only weak point is if someone finds out the domain for it and starts spamming the login screen. But I’ve restricted access to the domain for most of the world anyway. Wireguard would probably be more secure but its not always possible if like on vacation and want to use it on the TV there…
This is the biggest weakness of Jellyfin. Native OIDC support would really be a no brainer at this point.
It is possible if you get something like an nvidia shield tho. But of course not everyone has it or the money for it
Tailscale - funnel
Just that
