when reading through the jellyfin with chromecast guide i realized that it would probably be less effort to just let the casting api be public, with the added bonus that i could then cast my library to any device that supports it. but that seems like it would paint a giant target on the server.
what’s the recommended way of doing stuff like this? ideally i want to be able to go to someone’s house and just play some of my media on their tv.
not that any of this is doable in the near future, since i’m behind cgnat and won’t get my colocated bounce server up until spring.
As long as your jellyfin server is properly configured behind a reverse proxy, letting it be accessible publicly on the internet is fine.
Obviously everyone has their own threat model, but it’s not that big of a threat in this case (personally I don’t care).
This. People are overly paranoid nowadays.
I have had SSH open directly to my main PC for 15 years and never had any issues except spam logins. Just disallow password logins and you’re fine.
Same with :443 to my nginx.
Can you elaborate on ‘properly configured’?
The default configuration for Jellyfin is good. I mostly mean as long as you follow best practices in general you should be fine, eg:
- You keep your system and jellyfin updated;
- have some type of firewall in place;
- make sure you aren’t accidentally exposing jellyfins port directly to the internet;
- have a good password for your jellyfin accounts that are able to login from outside the LAN;
- and so on and so forth
https://jellyfin.org/docs/general/post-install/networking/reverse-proxy/
A firewall is probably the most important, having your ssh port blocked in the firewall being second.
Also, don’t use the default “data/media/{library name}” (or whatever the suggested format is) folder setup that the Trash Guide has you set up. At least change the “tv”, “movies”, etc name to something different. Jellyfin has a known vulnerability where an attacker can get access to media without valid credentials if they already know the file path. Jellyfin devs have stated that they have no intention of ever fixing this, because it would require completely divesting from the Kodi branch that everything is built on. And since everyone follows the Trash Guide to set their *Arr stack and library up, guessing file paths is laughably easy.
You’re using the suggested file naming in your *Arr stack, so Jellyfin can automatically match media? Congrats, so is everyone else. You’re using the suggested folder layout so your *Arr stack can use hardlinks? Congrats, so is everyone else. At least change the library folder names. Since your library folder doesn’t need to match the name of your Jellyfin library, you can literally have your “tv”, “movies”, and other folders be named whatever you want. Hell, name your tv folder “peepee” and your movies folder “poopoo” for all I care.
That certainly sounds like a thing you would want, nay need, to fix.
This needs to be copypasta’d as a reply to every comment suggesting that opening up jellyfin to the internet is easy and everyone should do it to get away from Plex.
My workaround will be to get a Chromecast or anything castable, a travel router (probably gli.net), setup a VPN and use that.
Any other device that’s outside of my home is unable to open a connection due to authelia intercepting the connection and the client unable to understand that.
An Idea I am also using for other things where I do not want to use a VPN:
- Setup a reverse proxy (e.g. traefik)
- Setup an oauth middleware for everything (forward Auth)
- Create rules to exempt very specific request based on IP, headers, etc… from the middleware.
In the casting use case you have to find a request and check if there is any parameter that you can use to safely whitelist the request. Ofcourse someone could get behind this and fake the request to match the whitelist. But without knowing that there is even a whitelist no one will really try
Dumb question: why does everyone is so terribly afraid of opening stuff to the internet ? What’s the scenario?
Allowing external access to your services means that any misconfiguration or bugs can be exploited to gain control of your machine(s).
Once that happens they can be fucked with, your data stolen, your resources co-opted for someone else’s use, etc. and often times it can be made to look as though whatever bad shit it’s doing is your doing.
So, understand your security posture. You can’t be too careful. Taking over weak or exposed machines is a global industry now.
But you can, in fact, be too careful. Availability is one arm of the security triad.
If whatever complex configuration you have set up to avoid exposing something to the Internet is incompatible with something and what you wanted to do can’t be done, or if you look and see that setting all that up would be too hard and don’t bother to expose the service at all, then your security posture is incorrect because your service is just as unavailable as if someone else broke it.
At the same time, taking over exposed machines has never been more difficult.
It starts with being used in a botnet. Then your data can be either erased, corrupted or encrypted against ransom.
i’ve set up servers with static ips in datacenter settings before. the way you know you’re online is usually that your cpu activity jumps a few percent from all the incoming ssh traffic from russia and china. i don’t want to risk anything happening to my home server.
so fun to look through the ssh log and see hundreds of attempts…
Quick question: If I look through the ssh log and I don’t see the hundred of attempts, what could be going on?..
Are you not actually open to the public internet? Is it running on a nonstandard port? Is it already pwned and something is scrubbing logs?
Non standard port. But aren’t secret chinese hack farm scanning wider than just 22 ? I don’t know and deep down believe that it’s pawned and scrubbing logs.
The resources required to port scan every port on every IP is generally not worth it. AFAIK they tend to stick to lower ports or popular ports. Unless they’re intentionally targeting a specific IP or IP range, they’re just looking for low hanging fruit.
Low hanging fruits are, in my personal case, pictures of my cats and public domain cultural artefacts.
Industrializing hacking of random servers sounds like a shitty idea at the end of the day…
I am not sure lol. perhaps your ssh port isn’t exposed to the internet, or maybe the bots are just ignoring you? maybe your hosting provider has some sort of security process to reject those attempts preemptively?
I have no clue
Ignoring ? Nah someone mentionned my ISP might be protecting me uphill.
The first thing I opened to the internet was a SSH server. 28 minutes after opening it, I started getting constant entry attempts.
Missconfigurations allowing bots and shit hacking you. Overblown paranoia mostly if you just take some precautions
Okay thanks for mentionning overblown paranoia, that’s what I have.
What kind of exploitable server misconfigurations are we talking about here?? Brute forcing won’t work because fail2ban, right? I’m a noob and deep down I’m convinced that my homeserver is compromised and has beenpart of a bitcoin mining farm for years… Yet, not a single proof…
my homeserver is compromised and has beenpart of a bitcoin mining farm for years
The very first Linux server I deployed on a VPS was hacked almost immediately because of my ignorance. The bot gained entrance, and they supplanted a miner rig. Now, on a tiny VPS, it’s pretty easy to tell if you’re running a coin miner because all of the resources will be pegged. However, I got to thinking, on a corporate server, if they did manage to do this, it would almost be undetectable until someone started reviewing logs.
Corporate servers will usually have some degree of SIEM implemented, and at least automatic audit log monitoring.
There are probably thousands of zero days out there in the hands of hacking organizations and nation state level actors. Exposing anything to the internet that doesn’t absolutely have to be is an invitation for the world to join your network and access all your files, if you’re okay with that risk then proceed
Aren’t zero day very specific? Or maybe it’s become a very generic term.
Anyway, I am under the impression that either it’s suddenly very simple to hack into EVERYONE because someone zero dayed the wireguard protocol and there a major flow in it, it’s a shitshow, for all, for some, just me or nobody, whatever. Or it’s a very targeted attack on me personaly, and that’s a whole other story and the means to protect my pictures of my cats and my cool public domain movies collection are different (think social engineering). Also port 22 being bombarded by brute force attempts so don’t choose a password that’s 6 letters thanks.
I KNOW I am missing many things, but still, I don’t get it.
In all likelihood a targeted attack would never come your way but when hosting community made software like immich for example there is a very large attack surface with no security researchers poking at it to find vulnerabilities of which there are likely many. Exposing something like nginx or Wireguard is likely very safe if properly secured because it’s been battle hardened over the decades with millions of eyes on it trying to break it at every turn. So what matters most is your threat model, what you’re deploying, and how you’re deploying it.
Fail2ban will protect you from brute force but just this week there was a maximum risk vulnerability found in react allowing remote code execution, this is one of the most used frameworks on the web developed by some of the most talented engineers in tech over a decade ago and it still has issues that could lead to malicious takeover of your system.
React2Shell is exactly the shitshow situation yes. Suddenly we are all at risk. But in this case, I’m sorry to say that my cats’ pictures are worthless.
Your point on nginx/wireguard makes me think that it might be better to htaccess through a reverse proxy than relying on a built in login system. For exemple, I should deactivate jellyfin’s login and put it behind an htaccess at the proxy’s level. Is that completely dumb?
Anyway, I clearly need to research “threat models” and cyber/infosec more. Thank you very much!
I’m paranoid dude, I don’t need the whole world judging my awful taste in TV shows!
I set up Jellyseer so my friends can request whatever. Just blame your full collection of My Little Pony and Gilmore girls on that one friend from Finland (unless you’re in Finland, and then use Greece).
lol
It’s not just opening stuff to the internet, it’s opening stuff to the internet without any authentication in this case. If you don’t know how that’s bad…….
Yeah sorry I missed the part where it has no authentification whatsoever, that’s just open bar.
Authentification + monitoring + fail2ban + ip blacklist
not that any of this is doable in the near future, since i’m behind cgnat and won’t get my colocated bounce server up until spring.
Doesn’t IPV6 allow direct external access even when cgnat is in use for IPV4?
Yes, if you have IPv6, you can open a port in the firewall and have external access. Whatever you are accessing it from must have IPv6 as well though.
that’s also a possibility, but i’m going to have to whine to my isp.
This video addresses many of the concerns of hosting stuff in public, and details a way (and some tools) to do it relatively securely. (There’s always a risk there’ll be a zero-day vulnerability in a web application like Jellyfin, but you can mitigate against them if you use the right strategies/tools, and you’re vigilant enough.)
Since you’re on cgnat, you can set up Pangolin on a VPS, or Tailscale–>rinetd–>Tailscale tunnel, also on a VPS. (Apparently frp is another similar solution, with p2p proxying.)
This is great thanks for this video
i like pangolin.
lol ive been saying that too much lately
i’ll worry about the nat traversal when i get my bouncer back up, but it will probably be less full-featured than pangolin. previously i just used a reverse ssh setup but that was a bit too rudimentary.
Yea I haven’t tried Pangolin myself - looks a bit bloated for my tastes, but I have tried rinetd across Tailscale and it worked brilliantly (very simple conf file), and I’ve done reverse ssh before (using autossh) which was a bit fiddly. frp does look promising though, just as a VPS<->home bridge.
Not spesifically helpful with your cgnat-situation, but my jellyfin runs on a isolated network and it’s just directly exposed to the internet via named reverse proxy in order to share the library with family and friends. Should someone get access to that they can obviously use the VM for nefarious purposes, but it’s a known risk for me and the attacker would need to breach trough either my VLAN isolation or out of the virtual environment to my proxmox host if they wanted to access my actually valuable data.
Sure, there’s bots trying every imaginable password combination and such, but in my scenario even if they could breach either the jellyfin server or reverse proxy it’s not that big of a deal. Obviously I keep the setup updated and do my best to keep bad actors out. but as I mentioned, breach for that one server would not be the end of the world.
With cgnat there’s not much else to do than to run a VPN where server is somewhere publicly accessible and route traffic via that tunnel (obviously running a VPN-client on jellyfin-server or otherwise routing traffic to it via VPN). Any common VPN-server should do the trick.
i like how everyone got hooked on the cgnat thing when i gave the actual solution in the main post. but yeah there’s always the option of not doing anything until i see issues.
EDIT: ddns does not work behind cgnat, only vpns and cloudflare tunnels do. my bad.
cgnat is doable with a dynamic dns service. you sign up free at duckdns, freedns, or desec, set up the subdomain you want (example.dedyn.io), install or host in a container a small ddns tool that will periodically (5 min typically) check what your current ip is and update your dns record with that dns service automatically with an api. some routers even have a dynamic dns setting so you can do it without a separate install.
as far as security, you’ll at a minimum want a long, unique password for any jellyfin accounts, and you should place it behind a reverse proxy like nginx, nginx proxy manager for a gui, caddy, or traeffik for some docker automagic fuckery i still don’t understand. i use nginx proxy manager, set up a wildcard *.example.dedyn.io certificate and force ssl on each service i’m forwarding.
you can get fanicer and have an authentication layer self hosted as well like authelia or authentik, but beware that apparently mobile apps and smart tv apps for jellyfin do not play nice because they use the same http port as web access and do not have the ability to pop open a web portal for a secondary auth and will not work with these yet. so it’s a good extra layer and 2fa sso addition but only if you use the webgui jellyfin and don’t rely on an app, which considering you’re asking about casting is probably not your use case.
what else you can do is set up a crowdsec or fail2ban service that will read logs from either the reverse proxy or jellyfin itself and ban ips thru your host firewall that fail to log in to help prevent bots from brute forcing in.
it’s not perfect but with a reverse proxy, ip banning tool, and strong, long passwords on jellyfin it should be relatively ok.
however it would probably be most secure to setup an openvpn or tailscale to vpn to your host and have a definitely secure link to jellyfin from everywhere. i don’t use these myself so i don’t know about limitations this way such as mobile app or smart tv app compatibility, though. and if you want to share with other users it comes with its own security considerations of letting others have a vpn into your host.
hope some of this helps, also there’s a cloudflare tunnel thing you can use instead of those dynamic dns services for domain redirect to ip behind cgnat, but i haven’t used it either and don’t know what all it entails.
good luck!
my registrar provides ddns, but how does that help with cgnat when thousands of people potentially have the same address?
oh dang, i thought i saw docs and comments saying ddns would help behind a cgnat too, must be mistaken. it’s just for isps who give semi-static ips that change, not full cgnat. after some quick googling it looks like tailscale or other vpn or cloudflare tunnel are your only options.
as i said i’m getting my bouncer server set back up next year after the datacenter it’s in has finished renovations, so actually getting a public address is not the biggest issue.
How often do you read that a jellyfin server was compromised?
I mean, anything with a web server can have vulnerabilities. Just look at the LastPass breach where hackers got in through an employee’s exposed Plex library.
Sure, software can always be vulnerable. What’s the difference between me consuming it from someone else or my private server?
Plex was running on his private computer, not a dedicated server, right? Windows? His version was 75 versions behind the current version at the time. How could the malware escape the server’s/plex’ sandbox? With a keylogger? Why wasn’t he using a password software? This isn’t the best example for your point
Plex was running on his private computer, not a dedicated server, right?
They opened it to the internet - that’s the big difference (and the topic at hand). Security is a multi-layered thing, but if your weakest point is a gaping hole, the rest doesn’t mean much. To my point - assuming Jellyfin ain’t gonna have vulnerabilities even when you’re fully up-to-date, is foolhardy.
Not every compromise is reported, or even detected.
If it’s not detected, reported and noone gets hurt, what’s the problem?
How do you know no one is being “hurt”?
How are you hurt if your jellyfin server is compromised and you don’t know about it?
That’s not a serious question, is it?
Hackers don’t report every time they hack someone, nor how they did it.
Jellyfin has a laundry list of security problems because it’s not designed to be directly exposed to the open internet
A VPN is the best option. You should be able to split-tunnel your jellyfin traffic and still see the device on the LAN.
i was sort of asking the opposite question to this answer, i think.
