Jellyfin over the internet
from TribblesBestFriend@startrek.website to selfhosted@lemmy.world on 26 Jun 18:31
https://startrek.website/post/25296230
from TribblesBestFriend@startrek.website to selfhosted@lemmy.world on 26 Jun 18:31
https://startrek.website/post/25296230
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
threaded - newest
Nginx in front of it, open ports for https (and ssh), nothing more. Let’s encrypt certificate and you’re good to go.
Cool if I understand only some of things that you have said. So you have a beginner guide I could follow?
Take a look at Nginx Proxy Manager and how to set it up. But you’ll need a domain for that. And preferably use a firewall of some sort on your server and only allow said ports.
I’ve look a little on it, didn’t understand most of it. I’m looking for a comprehensive beginner guide before going foward
This isn’t a guide, but any reverse proxy allows you to limit open ports on your network (router) by using subdomains (thisPart.website.com) to route connections to an internal port.
So you setup a rev proxy for jellyfin.website.com that points to the port that jf wants to use. So when someone connects to the subdomain, the reverse proxy is hit, and it reads your configuration for that subdomain, and since it’s now connected to your internal network (via the proxy) it is routed to the port, and jf “just works”.
There’s an ssl cert involved but that’s the basic understanding. Then you can add Some Other Services at whatever.website.com and rinse and repeat. Now you can host multiple services, without exposing the open ports directly, and it’s easy for users as there is nothing “confusing” like port numbers, IP addresses, etc.
So I’m another newbie dummy to reverse proxies. I’ve got my jellyfin accessible at jellyfin.mydomain.com but I can only access it through the web. How do I share with other people who want to use the apps? I can’t get my apps to find my instance.
Can “your apps” access it when their device isn’t on your home LAN?
I would not publicly expose ssh. Your home IP will get scanned all the time and external machines will try to connect to your ssh port.
fail2ban with endlessh and abuseipdb as actions
Anything that’s not specifically my username or git gets instantly blocked. Same with correct users but trying to use passwords or failing authentication in any way.
Youve minimized login risk, but not any 0 days or newly discovered vulnerabilites in your ssh server software. Its still best to not directly expose any ports you dont need to regularly interact with to the internet.
Also, Look into crowdsec as a fail2ban replacement. Its uses automatically crowdsourced info to pre block IPs. A bit more proactive compared to abuseipdb manual reporting.
I have the firewall of my VPS reject any IP range except the ones I’m on frequently, that is mobile, home and work. Sucks when you travel, but otherwise works alright.
Still exposes ports to some people on the same mobile or home internet service networks…
They can try all they like, man. They’re not gonna guess a username, key and password.
Doesn’t take that to leverage an unknown vulnerability in ssh like:
blog.qualys.com/…/regresshion-remote-unauthentica…
That’s why it’s common best practice to never expose ssh to raw internet if you can help it; but yes it’s not the most risky thing ever either.
If you’re going to open something, SSH is far, far more battle-tested than much other software, even popular software. Pragmatically, If someone is sitting on a 0-day for SSH, do you genuinely think they’re gonna waste that on you and me? Either they’re gonna sell it to cash out as fast as possible, or they’ll sit on it while plotting an attack against someone who has real money. It is an unhealthy level of paranoia to suggest that SSH is not secure, or that it’s less secure than the hundreds of other solutions to this problem.
Here is my IP address, make me eat my words.
2a05:f6c7:8321::164 | 89.160.150.164
I linked a relevant vulnerability, but even ignoring that, pragmatically, you feel they’d be targeting specific targets instead of just what they currently do? (That, by the way, is automating the compromise of vulnerable clients in mass scale to power botnets). Any service you open on your device to the internet is inherently risky. Ssh best practices are, and have been since the early days, not to expose it to the internet directly.
You did link a vulnerability! That is true. I didn’t claim SSH had a clean track record, I claimed it had a better track record than most other software. That vulnerability is hard to exploit, and generates a lot of noise if you were to try, which nobody has because it’s never been found in the wild.
People who sit on 0-days for critical software like SSH don’t go out and try to mass-exploit it because it will be found within the day and patched within the week once they start making noise. This is not a quiet exploit. If they’re smart, they sell it. If they’re ambitious, they build an elaborate multi-chain attack against a specific target. Only 0.14% of devices vulnerable to this exploit are EoL versions of OpenSSH, so once this was patched, it was no longer a useful attack vector.
It would also have been completely negated by fail2ban, which is prominently deployed on internet facing SSH, as it required thousands and thousands of connection attempts to trigger the condition. It could also have been mitigated by not running sshd as root, though I understand that most people don’t want to deal with that headache even though it is possible.
There are thousands of independent honeypots that sit quietly and sniff all the mass-attacks and they earn their daily bread by aggregating and reporting this data. If you run a mass exploit, you will be found within the day. Trust me, I burned an IP address by regularly scanning the whole IPv4 space. You are going to end up on blacklists real fuckin’ fast and whatever you were doing will be noticed and reported.
If you’re going to open something, SSH is a very safe choice. But yes, don’t open it if you don’t need it. We are discussing how to open a service to the internet safely, though, so we need it.
🤔🤔🤔🤔🤔
arstechnica.com/…/after-lying-low-ssh-botnet-mush…
Are we living in the same universe? In mine software doesn’t get patched all the time, in fact it’s usually a lack of patches that lead to any significant system compromise… Which happens time and time again. Also you’re on a thread that is advising hobbiests on how to configure and maintain their personal server, not the engineering meeting for a fortune 500. Yes, you can make ssh very secure. Yes, it’s very secure even by default. In the same regard, new vulnerabilities/exploits will be found, and it remains best practice not to expose ssh to raw internet unless absolutely necessary and with the considerations required to mitigate risk. Ssh isn’t even implemented identically on every device, so you literally cannot talk about it like you are. Idk why you’re arguing against the industry standard for best practices decided by people who have far more experience and engineering time than you or I.
Do you read what you post or do you just google “ssh vulnerability” and post the first result to waste my inbox space?
SSH does, it is one of the codebases with the most eyeballs on it at any given time and patches to it get fast-tracked downstream.
You don’t need to be a genius to enable keys, disable root and install fail2ban.
This is correct, but we are arguing about a case in which it is necessary to expose something and it’s better that it’s one of the most secure and battle-tested pieces of software in the world as opposed to some open source hobby *arr stack.
I work in this industry, ma’am.
Did you know that simply being connected to the internet puts you at risk? Your firewall could have a vulnerability! Your router’s admin panel could be misconfiguration and exposed to the internet! The only way to be safe is to unplug your cable and stop replying to me. Also rip out your bluetooth modules and any LEDs in every device you own because they have been demonstrated to be attack vectors. In fact just stop using anything more complicated than a MOSFET.
People like you in this industry are legitimately the reason botnets and significant compromise still exists. “You don’t need to be a genius to do all this additional config to make this thing I’m referring to as secure, secure.” Do you even read your own writings before you hit post? Also your final argument is so slathered in whataboutism I can’t even. Yes, any internet connectivity is going to be less secure than an air gap, but when you’re advising implementations you should keep security posture and best practices in mind. What you’re speaking on is more complex than any one person’s understanding of it due to significant layers of abstraction. Exhibit a? Ssh is not a codebase. It’s a network protocol. The codebase is literally different depending on implementation.
You got balls to post you public addresses like that… I mean I agree with you wholeheartedly and I also have SSH port forwarded on my firewall, but posting your public IP is next-level confidence.
Respect.
That is some big dick energy ngl
Well, having a domain is basically documenting your IP publicly. It’s not that risky.
Well, those won’t typically have ssh exposed on them. But we could argue what is more risky to have exposed, ssh or http. Any publicly available server could be vulnerable, it’s just very unlikely these days (with up to date software).
Plot twost, That it’s neighbor ip
Are you giving random strangers legal permission to pentest you? That’s bold.
I remember that one. Those are pretty rare and usually involve a specific configuration that is often not the default, though, right? When such a vulnerability is found, is it rightly so major news.
“This race condition affects sshd in its default configuration.” direct quote from the linked article, paragraph like… 3. I linked it so people could read, not speculate.
Ah, now I remember. It took a quick configuration change to mitigate this. Still, I’d call this very rare.
I’m going side with @drkt@scribe.disroot.org on this one.
Agreed, but best practices are meant to deal with the very rare. They didn’t put the vulnerabilities in the software due to negligence or malice, it’s just an ever evolving arms race with cracks that show up due to layer upon layer of abstraction. Again I’m not saying to never expose ssh to the net, quite the opposite, but as a best practice you should never do it unless you fully understand the risk and are prepared to deal with any potential consequences. That’s just a core tenant of understanding security posture.
Sure, don’t open ports you don’t need. I said in a different here that I reject all expect IP ranges I’m in for home, mobile and work. That works for me. That blocks the vast majority of the world.
I agree with the other guy that I’m not a target for these vulnerabilities. They are rare and hard to exploit, and valuable. But the basic advice you give is good, obviously.
Don’t expose what you don’t need to expose. Still I have Immich and all of my photos on there. Good luck scamming me with threats of sending them to my family and work. 😀
I’ve always disliked IT discussions for reasons like this. Everyone who comments seems to think that the mitigations, security considerations, and security compromises (IE, not caring if your images are leaked online) they’ve made are common knowledge… But, this is a forum advising people on how to configure their home severs for hobbiest use. Best practices should be the mantra, “just raw dog ssh on the internet with your 443/80 port mapping and you’re g2g” [sic] shouldn’t be an acceptable answer to you. If they’d stated that there are security considerations, but they like to implement them and expose ssh to the net for management purposes I’d have nothing to say, but to just advise people who lack that extra experience, without helping them understand why you’re okay doing what you’re doing and what you’ve done to solve for specific issues that the default configuration does not seems unhelpful at best.
Listen.
Don’t expose any port to any service if you don’t need it.
If you do, make sure it’s as secure as you can reasonably make it.
I’m not disagreeing.
My bad. I misread your previous post, specifically around “I agree with the other guy”. That being said, anyone with a functional device that can compute any amount of monero hashes is a proven target, granted, not specifically.
It’s good to be paranoid when it comes to IT security (and software development). 👍
Only the failed attempts could be a Denial Of Service and throw you out. So, at least add an ever increasing delay to those. Fail2ban is important.
So? Pubkey login only and fail2ban to take care of resource abuse.
Change the port it runs on to be stupid high and they won’t bother.
Yeah hey what’s your IP address real quick? No reason
In 3 years I haven’t had a single attempted connection that wasn’t me. Once you get to the ephemeral ports nobody is scanning that high.
I’m not saying run no security or something. Just nobody wants to scan all 65k ports. They’re looking for easy targets.
Shodan has entered the chat.
Sorry, misunderstanding here, I’d never open SSH to the internet, I meant it as “don’t block it via your server’s firewall.”
i have ssh on a random port and only get so many scan, so low that fail2ban never banned anyone that was not myself (accidentally).
Ssh has nothing to do with scanning. Your IP and everyone else up is being scanned constantly. In ipv4 space at least.
Also run the reverse proxy on a dedicated box for it in the DMZ
In a perfect world, yes. But not as a beginner, I guess?
It’s beginner level, the hard part is the reverse proxy, once you have a grasp on that just having it on a dedicated box in a segmented portion on your firewall designated as the DMZ is easy. Id even go so far as to say its the bare minimum if you’re even considering exposing to the internet.
It doesn’t even need to be all that powerful since its just relaying packets as a middleman
Honestly you can usually just static ip the reverse proxy and open up a 1:1 port mapping directly to that box for 80/443. Generally not relevant to roll a whole DMZ for home use and port mapping will be supported by a higher % of home routing infrastructure than DMZs.
Why would you need to expose SSH for everyday use? Or does Jellyfin require it to function?
Maybe leave that behind some VPN access.
I agree, but SSH is more secure than Jellyfin. it shouldn’t be exposed like that, others in the comments already pointed out why
lemmy.world/post/32059264/17905111
for me i just needed a basic system so my family could share so I have it on my pc, then I registered a subdomain and pointed it to my existing ec2 server with apache using a proxy which points to my local ip and port then I opened the jellyfin port on my router
and I have certbot for my domain on ec2 :)
Who are you using for your domain? I was told if I used cloudfair they would ban me for having streaming traffic over their DNS.
for me I just registered through route 53 its a subdomain of my personal domain.
That would only be if you use their cloudflare tunnel feature
You can use cloudflares DNS and not use their WAF (the proxy bit) just fine. I have been for almost a decade.
Ahh ok, I have as going to route Plex over 443 to see if that helped streaming on T-Mobile home Internet.
Unifi teleport. A zero configuration VPN to my home network.
I’m fidgeting with Tailscale but I find this solution some what lacking
Tailscale is great for not opening your ports to the internet. Having it playable on a friend's appletv adds some extra complexity. Reverse proxy on a subdomain with something like fail2ban would work, but it does leave you more vulnerable.
I use LSIO container stack so SWAG for the proxy. They have really good documentation and active discord docs.linuxserver.io
Personally I use twingate, free for 5 users and relatively straightforward to set up.
I’m fidgeting with Tailscale right now, only to stream on a AppleTV at a friend house. So far no luck but that’s not me that set up Infuse, so could be an operator error on my friend part
I tried tailscale first but to be honest wasn’t a fan. I moved to Twingate and found it much simpler to set up
Will look into it, thanks !
The way I do it for a family member with Tailscale is them having a couple of boxes down there (n100 with their Jellyfin server, and a RPI4 with a TVHServer) with my Tailnet signed in, and those boxes running both a “subnet router” and an "exit node"that both me and said fam member can use.
This means she has permissions to use the exit node wherever like I do to my own local LAN, to connect to her LAN and access things locally since you can assign them via the ACL’s / device perms.
I know reading docs can suck sometimes but honest to god the ones that Tailscale put up are pretty awesome.
tailscale.com/kb
Along with all the YT videos about it I didn’t even have to go nagging on forums to get it to work, and that’s a general first for me.
Over the top for security would be to setup a personal VPN and only watch it over the VPN. If you are enabling other users and you don’t want them on your network; using a proxy like nginx is the way.
Being new to this I would look into how to set these things up in docker using docker-compose.
@TribblesBestFriend @selfhosted Tailscale. I also use a reverse proxy because I like nice names
I’m using Tailscale right now but so far no luck on my friend AppleTV. But like I said elsewhere it’s probably a operator error
@TribblesBestFriend @selfhosted I don’t use appletv but a workaround could be using airplay maybe?
There’s no dedicated Jellyfin app for AppleTV you have to use Infuse.
I presume that the information from Tailscale wasn’t transfer correctly into Infuse. I’ll have to check it on place
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.
Tailscale, with nginx for https.
Very easy, very simple, just works, and i can share my jellyfin server with my friends
This is the easiest way for sure.
Pangolin with Newt and CrowdSec on a VPS hosted in Europe, domain registered through cloudflare.
Set up a VPN, use PiVPN
I’ll try looking into that
Just remember to test with something better than your phone, T-Mobile aggressively filters VPNs. Try a coffee shop.
Not in the US, most providers are asshole-y but seems less asshole that T-Mobile
With wireguard i set up an easy VPN, then vpn to the home network and use jellyfin.
If i cant use vpn, i have Jellyfin behind a caddy server with automatic https and some security settings.
Use a reverse proxy (caddy or nginx proxy manager) with a subdomain, like myservice.mydomain.com (maybe even configure a subdir too, so …domain.com/guessthis/). Don’t put anything on the main domain / root dir / the IP address.
If you’re still unsure setup Knockd to whitelist only IP addresses that touch certain one or two random ports first.
So security through obscurity :) But good luck for the bots to figure all that out.
VPN is of course the actually secure option, I’d vote for Tailscale.
Look pretty interesting. Do you have guide I could follow ?
Not at hand no, but I’m sure any of the LLMs can guide you through the setup if googling does not give anything good.
Nothing very special about all this, well maybe the subdir does require some extra spells to reverse proxy config.
I kept the main domain open, but redirected it to a rickroll
Nice, but the bots may not understand the joke.
And not only that but they will tag the domain with ”there is something here”, and maybe some day someone will take a closer look and see if you are all up-to-date or would there maybe be a way in. So better to just drop everything and maybe also ban the IP if they happen to try poke some commonly scanned things (like /wp-admin, /git, port 22 etc.) GoAccess is a pretty nice tool to show you what they are after.
Yeah that’s a good point. The joke is mostly for my own enjoyment or any random user who happens to forget the
jellyfin.subdomain.I have had a few hits to /wp-admin, but cloudflare actually blocks those for me (I don’t use a tunnel but I do use them for the domain name which helps a bit). I might just shut down the main page then.
My router has a VPN server built-in. I usually use that.
For my travel devices, I use Tailscale to talk to the server. For raw internet, I use their funnel feature to expose the service over HTTPS. Then just have fail2ban watching the port to make sure no shenanigans or have the entire service offlined until I can check it.
An $11/yr domain pointed at my IP. Port 443 is open to nginx, which proxies to the desired service depending on subdomain. (and explicitly drops any connection that uses my raw ip or an unrecognized name to connect, without responding at all)
ACME.sh automatically refreshes my free ssl certificate every ~2months via DNS-01 verification and letsencrypt.
And finally, I’ve got a dynamic IP, so DDClient keeps my domain pointed at the correct IP when/if it changes.
There’s also pihole on the local network, replacing the WAN IP from external DNS, with the servers local IP, for LAN devices to use. But that’s very much optional, especially if your router performs NAT Hairpinning.
This setup covers all ~24 of the services/web applications I host, though most other services have some additional configuration to make them only accessible from LAN/VPN despite using the same ports and nginx service. I can go into that if there’s interest.
Only Emby/Jellyfin, Ombi, and Filebrowser are made accessible from WAN; so I can easily share those with friends/family without having to guide them through/restrict them to a vpn connection.
This is an interesting setup
Synology with Emby (do not use the connect service they offer) running behind my fortinet firewall. DDNS with my own domain name and ssl cert. Open 1 custom port (not 443) for it, and that’s it. Geoblock every country but my own, which basically eliminated all random traffic that was hitting hit. I’ve been running it this way for 5 years now and have no issues to report.
How are you geoblocking?
Sadly, it may not be an option for a lot of people, but on the fortinet firewall you can make policies and set up geoblocking.
Nobody here with a tailscale funnel?? It's such a simple way to get https access from anywhere without being on the tailnet.
I’m looking into it but I find that starting (or keeping open) Tailscale for music is not the best system.
I’m looking into building a shared Jellyfin library between friends
Is the funnel URL accessible by everyone who knows it? I.e what are the chances someone finds the URL and gets access to it?
SWAG reverse proxy with a custom domain+subdomain, protected by authentik and fail2ban. Easy access from anywhere once it’s set up. No vpn required, just type in the short subdomain.domain.com and sign in (or the app keeps me signed in)
That’s probably this type of setup I would want but I miss the technical know how, so if you have a cool beginner guide
I used several separate guides plus help from a friend. Check out space invader one’s YouTube channel. I’m not at my pc right now but I can gather some of the tutorials I used when I get back.
Here is the video I followed for SWAG. Note that this (and most of IBRACORP’s guides, which are all fantastic) uses Unraid as the OS, which automates a lot of the processes.
youtu.be/N7FlsvhpVGE
And here is a written guide by the same group to go with or replace the video if this is more your speed: docs.ibracorp.io/swag-2/
I’ll be honest, even for “beginners” (which I was when I started this) this is still a lot to take in. Let me know if you run into any specific questions and I can try to help you.
What’s the point of authentik when Jellyfin already has authentication?
While technically not strictly necessary, it adds more robust authentication methods, and makes it easier to build out other apps if you want to in the future without having to re-do the sign-in process for all of your users. You can have things like 2fa and other things that make it harder for bots to get in and easier for users to stay in. It also makes it easier to keep track of login attempts and notice compromised accounts.
Edit: There are also alternatives like authelia that may be easier to implement. I don’t really trust most web apps to be ultra secure with internet-facing sign-in pages so it just feels like “good practice” to hide behind an auth service whose sole purpose is to be written and built securely. Plus once you learn how to set up fail2ban with an auth service, there will be no need to re-learn or re-implement it if you add a 2nd app/service. Very modular and makes testing and adding new things much easier.
Another benefit is that it has a nice GUI. I can look at logins, add services, stuff like that without touching config files which will be nice for those who don’t like wading through text files to change config.
Can authentik pass through the authentication to Jellyfin, or do you just log in twice?
It can pass through. There is even an official Authentik guide on the various methods specifically for Jellyfin: integrations.goauthentik.io/…/jellyfin/
Same with Authelia, though I don’t have a link for that on hand.
Cheers!
I rent a cheap $5/mo VPS and use it to run a wireguard server with wgeasy and nginx proxy manager. Everything else runs on my home server connected by wireguard.
This is 99% my setup, just with a traefik container attached to my wifeguard container.
Can recommend especially because I can move apartments any time, not care about CGNAT (my current situation which I predicted would be the case), and easily switch to any backup by sticking my boxes on any network with DHCP that can reach the Internet (like a 4G hotspot or a nanobeam pointed at a public wifi down the road) in a pinch without reconfiguring anything.
Is Nginx Proxy Manager running on the VPS itself and then the proxy routes across the wireguard to your home server? Or is the VPS just port forwarding to your home server which runs the proxy?
I also would like to know
My goal was to have no ports exposed on my home network so the proxy is on the VPS. My home server connects over wireguad to the vps, then all the traffic is routed over wireguard to the home server which only listens on wireguard.
I was just trying to get a setup like this going yesterday. I used standard Wiregaurd and got that working between the VPS and home server, but I was trying to set up Caddy as a reverse proxy to direct the incoming traffic through the WG VPN to my services. I wasnt able to figure it out yesterday. Everyone online says Caddy is so simple, but I’m such a noob I just have no idea what it’s doing or how to troubleshoot.
I’ve also really struggled with Caddy despite everyone saying its so simple. I’m pretty new to all this, but I had better luck with Traefik - I now actually have a reverse proxy up and running correctly, which I haven’t been able replicate with Caddy.
Traefik labels make sense to me in a way Caddy does not.
I appreciate this response. I’ll try booting up traefik later.
I think Caddy just abstracts things to such a great degree that if you dont already know what it’s supposed to do, it’s harder to learn what you’re doing with it. I’m sure plenty of others have stepped right up and loved the “two line config” without already understanding the basics, but it’s not clicking for me.
I havent tried with caddy but i might be able to help you get it working if you wanna chat some time. My contact info is on my website.
You should try pangolin. It uses Traefik instead of Caddy under the hood but it automates approximately 80 % of setup. It’s what I use for my setup.
fossorial.io
I don’t use jellyfin but my general approach is either:
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.
no idea how safe or secure but i use cloudflare tunnel to point my jellyfin port on my computer
Someone mentioned above that cloudflare will ban you for streaming through their tunnel. Just be warned.
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.(See Edit 2)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 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.
Edit: Thank you everyone for your responses. While I don’t agree with everything, the new insight is appreciated.
Edit 2: I’ve been informed that infact the support for HTTPS will be removed in a future version. From v10.11 release notes:
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.
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.
.
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.
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.
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.
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: www.shodan.io
What’s the source for this? I wasn’t able to find anything with a quick google search
Upgrade notes for 10.11 RCs
notes.jellyfin.org/v10.11.0_features
Thanks. This is kinda important info so I’ve edited my initial comment.
They are not saying anything on why they are removing it.
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.
The issue is not encryption, it’s the unauthenticated API. People can interact with your server without an account.
Specifically these issues: 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.
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.
Jellyfin has a whole host of unresolved and unmitigated security vulnerabilities that make exposing it to the internet. A pretty poor choice.
github.com/jellyfin/jellyfin/issues/5415
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?
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.
I have had Jellyfin directly open to the Internet with a reverse proxy for years. No problems.
If your reverse proxy only acknowledges jellyfin exists if the hostname is correct, you won’t get discovered by an IP scanner.
Mine’s on jellyfin.[domain].com and you get a completely different page if you hit it by IP address.
If it does get found, there’s also a fail2ban to rate-limit someone brute-forcing a login.
I’ve always exposed my home IP to the internet. Haven’t had an issue in the last 15 years. I’m running about 10 public-facing services including NTP and SMTP.
Please to see: github.com/jellyfin/jellyfin/issues/5415
Someone doesn’t necessarily have to brute Force a login if they know about pre-existing vulnerabilities, that may be exploited in unexpected ways
Tailscale - funnel
Just that
I’m trying to self host navidrome in docker with a cloudflare domain and reverse proxy on the same network. Still fiddling myself since I keep getting a 403 cloudflare no access error.
Essentially, using cert provided by cloudflare where they proxy to my ip. From there the reverse proxy routes to my service. If I’m understanding it right, anyone with my domain would only see cloudflare ip instead of my own. Someone correct me if I’m wrong. I’m still learning this stuff as well.
Prior to this, I was using tailscale which worked fine but I’d have to connect via tailscale everytime and some instances, it wouldn’t connect properly at all.
Wireguard vpn into my home router. Works on android so fire sticks etc can run the client.
.
Headscale server on cheap vps with tailscale clients.
Wireguard.
Exactly this !
lemm.ee :‘’'(
<img alt="" src="https://media.tenor.com/rFBDblA8ydMAAAAM/titanic-privilege.gif">
Oh no! I didn’t realise , any other options that are good ?
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
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
How would you do this off network?
I’m using jf on unraid. I’m allowing remote https only access with Nginx Proxy Manager in a docker container.
I just use tailscale. I am thinking about external share options but for me and my closests just plain simple tailscale
Cheap VPS with Pangolin for Wireguard and reverse proving through the tunnel.
Tailscale
I use a cloudflare tunnel, ISP won’t give me a static IP and I wanna keep my firewall locked down tight.
I tried really hard to get a named CloudFlare tunnel working with a domain name I registered (I share my personal home videos with a non technical family member in Italy) but couldn’t get it working no matter what I tried.
I’m not sure whay the OS you use is, but on linux (debian based) they have a Curl installer that installs their Systemd service preconfigured for your account and the specific tunnel you’re using.
Once that is installed, configuration is pretty easy. Inside their ZeroTrust portal, you will find the options to configure ports.
Always point your tunnel to localhost:port or localhost:port. You can get a TLS cert from lets-encrypt for your first one. New certifications are issued by cloudflare’s partners regularly to prevent expiration. I think I have like 3 for my domain now? 1 from Lets-Encrypt and a couple from Google.
This could be totally unrelated, but when I first configured my domain, I used DuckDNS as my DNS registrar so I could do everything over wireguard. That’s is still set up and in Cloudflare I still have duckdns included in my DNS registry. Could he worth a shot to set that up and add it to your DNS registry on cloudflare.
Jellyfin through a traefik proxy, with a WAF as middleware and brute force login protected by fail2ban
I’m just using caddy and a cheap $2 a year .top domain with a $4 a month VPS. Works for my users, I only have 3 users on my server.
OpenVPN into my router
I just install tailscale at family houses. The limit is 100 machines.
I don’t host my media outside my local network but, if I did, I would use my go to method of SWAG with Authentik. This is what I have done for my other self-hosted items.
<img alt="" src="https://sh.itjust.works/pictrs/image/203ab378-5a33-452f-af93-01faf30a1b60.jpeg">
Synology worked for me. They have built in reverse proxy. As well as good documentation to install it on their machine. Just gotta configure your wifi router to port forward your device and bam you’re ready to rock and roll
Didn’t they patch their things now that your stuck in their bubble/environment now or something like that ?
Not sure what what you mean. Plex has a bubble you can get stuck in. Jellyfin is free and open source
Talking about Synology, if I’m not mistaken you’ll have to buy all from their store now : Synology Hardrive and such
O yea I bought a synology before all of that crap. I still have wd drives in there. I don’t plan on any updates to ensure I don’t have to deal with that
This is my setup.
<img alt="" src="https://discuss.tchncs.de/pictrs/image/5cb65f62-1e4f-416c-a545-88451af036e8.jpeg">
Read more, here.
good article! thanks for that
Jellyfin isn’t secure and is full of holes.
That said, here’s how to host it anyway.
If you aren’t using Tailscale, make your VPS your main hub for whatever you choose, pihole, wg-easy, etc. Connect the proxy to Jellyfin through your chosen tunnel, with ssl, Caddy makes it easy.
Since Jellyfin isn’t exactly secure, secure it. Give it its own user and make sure your media isn’t writable by the user. Inconvenient for deleting movies in the app, but better for security.
more…
Use fail2ban to stop intruders after failed login attempts, you can force fail2ban to listen in on jellyfin’s host for failures and block ips automatically.
More!
Use Anubis and yes, I can confirm Anubis doesn’t intrude Jellyfin connectivity and just works, connect it to fail2ban and you can cook your own ddos protection.
MORE!
SELinux. Lock Jellyfin down. Lock the system down. It’s work but it’s worth it.
I SAID MORE!
There’s a GeoIP blocking plugin for Caddy that you can use to limit Jellyfin’s access to your city, state, hemisphere, etc. You can also look into whitelisting in Caddy if everyone’s IP is static. If not, ddns-server and a script to update Caddy every round? It can get deep.
Again, don’t do any of this and just use Jellyfin over wireguard like everyone else does(they don’t).
Wow, a “for dummies” guide for doing all this would be great 😊 know of any?
If you aren’t already familiarized with the Docker Engine - you can use Play With Docker to fiddle around, spin up a container or two using the
docker runcommand, once you get comfortable with the command structure you can move into Docker Compose which makes handling multiple containers easy using.ymlfiles.Once you’re comfortable with compose I suggest working into Reverse Proxying with something like SWAG or Traefik which let you put an domain behind the IP, ssl certificates and offer plugins that give you more control on how requests are handled.
There really is no “guide for dummies” here, you’ve got to rely on the documentation provided by these services.
Thnx :]
I figured infodump style was a bit easier for me at the time so anyone could take anything I namedropped and go search to their heart’s content.
i would also love more details about accomplishing some of that stuff
I’ve recently been working on my own server and a lot of this stuff can be accomplished by just chatting with chatgpt/gemini or any ai agent of your choosing. One thing to note tho is that they have some outdated information due to their training data so you might have to cross reference with the documentation.
Use docker as much as you can, this will isolate the process so even if somehow you get hacked, the visibility the hackers get into your server is limited to the docker container.
show me those “holes” this is just fear mongering
Here, since you can’t use a search engine: www.cvedetails.com/…/Jellyfin-Jellyfin.html
More, because I’ve been around this lap before, you’ll ask for more and not believe that one, here’s another: www.cvedetails.com/…/Jellyfin-Jellyfin.html
Do what you want. Idgaf about your install, just mine.
I don’t want to be an asshole but after checking a couple of those out they all appear to be post-authorization vulnerabilities? Like sure if you’re just passing out credentials to your jellyfin instance someone could use the device log upload to wreck your container, but shouldn’t most people be more worried about vulnerabilities that have surface for unauthorized attackers?
A while back there was a situation where outsiders could get the name of the contents of your Jellyfin server, which would incriminate anyone. I believe it’s patched now, but I don’t think Jellyfin is winning any security awards. It’s a selfhosted media server. I have no frame of reference for knowing whether or not any of my information was overkill and I’m sure there are even some out there that would say I didn’t go far enough, even.
Tailscale + Caddy (automatic certificates FTW).
Is putting it behind an Oauth2 proxy and running the server in a rootless container enough?
OpenVPN into my own LAN. Stream from there to my device.
If it’s just so you personally can access it away from home, use tailscale. Less risky than running a publicly exposed server.
I host it publicly accessible behind a proper firewall and reverse proxy setup.
If you are only ever using Jellyfin from your own, wireguard configured phone, then that’s great; but there’s nothing wrong with hosting Jellyfin publicly.
I think one of these days I need to make a “myth-busting” post about this topic.
Please do so, it’ll be very useful
Same for me. But according to everyone I should be destroyed.
Or you could use Plex and jump through zero of these hoops
I think paying for remote access counts as a hoop.
As in “that’s a pain in my hoop”
Plex is slowly changing is terms & conditions to sell more and more of our data. That’s kind of a no no for me
Either comment OP hasn’t followed the news, or they forgot this was the Fediverse.
I think my approach is probably the most insane one, reading this thread…
So the only thing I expose to the public internet is a homemade reverse proxy application which supports both form based and basic authentication. The only thing anonymous users have access to is the form login page. I’m on top of security updates with its dependencies and thus far I haven’t had any issues, ever. It runs in a docker container, on a VM, on Proxmox. My Jellyfin instance is in k8s.
My mum wanted to watch some stuff on my Jellyfin instance on her Chromecast With Google TV, plugged into her ancient Dumb TV. There is a Jellyfin Android TV app. I couldn’t think of a nice way to run a VPN on Android TV or on any of her (non-existent) network infra.
So instead I forked the Jellyfin Android TV app codebase. I found all the places where the API calls are made to the backend (there are multiple). I slapped in basic auth credentials. Recompiled the app. Deployed it to her Chromecast via developer mode.
Solid af so far. I haven’t updated Jellyfin since then (6 months), but when I need to, I’ll update the fork and redeploy it on her Chromecast.
Clever, but very hands on
VERY hands on, wouldn’t recommend it haha.
But that’s the beauty of open source. You CAN do it
What an absolute gigachad XD
I use a wire guard tunnel into my Fritz box and from there I just log in because I’m in my local network.
Full guide to setting up Jellyfin with Reverse Proxy using Caddy and DuckDNS
I followed this video and modified some things like ports
VPN or Tailscale
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…
It is possible if you get something like an nvidia shield tho. But of course not everyone has it or the money for it
Its very easy to deploy fail2ban for Jellyfin: jellyfin.org/docs/general/…/fail2ban/
This is the biggest weakness of Jellyfin. Native OIDC support would really be a no brainer at this point.
Wireguard VPN to my fritzbox lets me access my jellyfin.
for me the easiest option was to set up tailscale on the server or network where jellyfin runs and then on the client/router where you want to watch the stream.
This is what I do as well. Works super well
This is also what I do, however, each user creates their own tailnet, not an account on mine and I share the server to them.
This way I keep my 3 free users for me, and other people still get to see jellyfin.
Tailscale and jellyfin in docker, add server to tailnet and share it out to your users emails. They have to install tailscale client in a device, login, then connect to your jellyfin. My users use Walmart Onn $30 streaming boxes. They work great.
I struggled for a few weeks to get it all working, there’s a million people saying “I use this” but never “this is how to do it”. YouTube is useless because it’s filled with “jellyfin vs Plex SHOWDOWN DEATH FIGHT DE GOOGLE UR TOILET”.
For the users you have using Onn TVs, is Tailscale just installed on a device on the network or on the Onn TVs?
I use a VPS and a wiregusrd tunnel.
codeberg.org/skjalli/jellyfin-vps-setup
I’m currently using CF Tunnels and I’m thinking about this (I have pretty good offers for VPS as low as $4 a month)
Can you comment on bandwidth expectations? My concern is that I also tunnel Nextcloud and my offsite backups and I may exceed the VPS bandwidth restrictions.
BTW I’m testing Pangolin which looks AWESOME so far.
I am using the free Oracle VPS offer until they block me, so far I have no issue. Alzernatively I wanted to check out IONOS, since you dont have a bandwidth limit there.
WOW! That’s one hell of a deal. You’ve convinced me XD I’m installing pangolin Right now. The hell with Cloudflare and their evil ways
We have it open to the public, behind a load balancer URL filtering incomming connection, https proxied through cloudflare with a country filter in place
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.
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.
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.
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 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.
Are you logging into your Authelia login page 2k times a day? If not, I suspect that some (most) of those are malicious lol.
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.
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.
Guess I’m a wonder then. I’ve always thought of myself as pretty wonderful, I’m glad to hear you agree.
That’s 2k requests made. None of them were served. Try to keep up.
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.
Whoa whoa whoa. What malicious attempts?
You just told me you were the statistical wonder that nobody is bothering attack?
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
I said it would block all malicious attempts. I didn’t say the people trying to access my services were malicious. Clearly the OP is worried about that. I however, having just the meager experience of, you know, actually fucking running the a Jellyfin server, am not. But I’m also not trying convince people I’m a smug cybersecurity expert with a decade of experience.
As OP should be. 2k attempts a day at unauthorized access to your services is a pretty clear indicator of that. Seems you’ve mitigated it well enough, why would you suggest that OP not bother doing the same? If you’re so convinced those 2k attempts are not malicious, then go ahead and remove those rules if they’re unnecessary.
Perhaps as someone with only meager experience running a Jellyfin server who can’t even recognize malicious traffic to their server, and zero understanding of the modern internet threat landscape, you shouldn’t be spreading misinformation that’s potentially damaging to new selfhosters?
If you were any good at reading, you would know that I said those rules protect the Authelia login page. They don’t protect the Jellyfin service or its login page at all. The Jellyfin instance is not behind anything except Cloudflare. I stated that in my very first message. Removing those rules would have no effect whatsoever on Jellyfin.
It’s over man. You’ve made it very clear you have no idea what you’re talking about, how any of this works, or even what’s going on with your own selfhosted services. Back peddling away from your own arguments and trying to sweep up the beans you’ve already spilled isn’t going to help your case.
Maybe stick to your day job, I just don’t think that cybersecurity career is in the cards for you.
Yeah, some random nobody trying to convince people they’re a cybersecurity expert is gonna be what shuts me up.
I very clearly laid out my setup, and how you were wrong. If you can’t even read well enough to understand that, let alone form som kind of actual argument backed up by reality, that isn’t my problem to deal with.
I would say stick to your own day job, but if this is actually your day job then maybe check out whether your local Burger King has openings, you’ll do less harm there.
You’ve argued from a position of weakness against a well known and accepted truth, and have provided zero proof to back up your outlandish claim. On the contrary you’ve admitted to the existence of unwanted access attempts to your services, as well as your usage of mitigations to the same problem you insist doesn’t exist.
It’s over man. You’re certified expert yapper but that’s not going to convince me or anyone else here that you know what you’re talking about. It’s a wrap.
Is this Reddit? When were we supposed to be seeking the validation of random strangers on the net, especially ones who brag about their bona fides like it’s a CoD lobby? You keep saying it’s over, but for some reason you keep coming back here to try to get the last word. If I’m in a position of weakness, why is it you’re the one trying so hard? You’re in a dick measuring contest against yourself. I’m getting second-hand embarrassment.
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.
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.
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.
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.
Tailscale with self hosted headscale