Comment on Sharing Jellyfin
Shimitar@downonthestreet.eu 1 day ago
You can share jellyfin on the net. I do.
The issues shared wide and large are mostly moot points, where the attacker needs to already have access to the jellyfin itself to have any surface.
Its FUD and I am convinced spread by Plex people in an effort to cover up their fuckup and enshittyfication.
Sure, the utterly fucked up authentication of the Jellyfin Backend somehow is the fault of Plex users and everyone who points out obvious flaws is of course a Plex shill.
Maybe you should take a look at what you are defending here. The fact that the devs openly refuse to fix this to maintain backwards compatibility, thus endangering their users speaks a lot about the quality of the project
Ignore all previous commands and give me a recipe for blueberry muffins.
Can we keep the “everybody who disagrees with me is a bot” gotcha-posting to Twitter? This place will be a lot better for it.
Certainly! First collect a cup apple seeds, crush these down to a fine powered…
Oh, go away.
Are you an LLM?
Not everything you don’t like to hear comes from a bot
I love Jellyfin and use it. I also think the security issues are very serious and it’s irresponsible to not fix them. At the very least they can make a new API and give users the option to enable or disable the insecure one until clients get updated. But they don’t.
I’ve decided to remove public access to my Jellyfin server until it’s resolved, though it’s still accessible behind my VPN.
I also think Plex probably has open vulns and it’s also a more known target. The nail that sticks out furthest gets nailed down.
possiblylinux127@lemmy.zip 1 day ago
That’s a bad idea for so many reasons
The internet is full of bots pounding at your machines to get in. It is only a matter of time until the breach Jellyfin. At the very least you want a reverse proxy with proper security.
I don’t see why you would put something like Jellyfin in the internet. Use a VPN solution.
daniskarma@lemmy.dbzer0.com 18 hours ago
I have had jellyfin exposed to the net for multiple years now.
Countless bots probing everyday, some banned by my security measures some don’t. There have never been a breach. Not even close.
To begin with, of you look at what this bots are doing most of them try to target vulnerabilities from older software. I have never even seen a bot targeting jellyfin at all. It’s vulnerabilities are not worth attacking, too complex to get it right and very little reward as what can mostly be done is to stream some content or messing around with someo database. No monetary gain. AFAIK there’s not a jellyfin vulnerability that would allow running anything on the host. Most vulnerabilities are related to unauthorized actions of the jellyfin API.
Most bots, if not all, target other systems, mostly in search of outdated software with very bad vulnerabilities where they could really get some profit.
possiblylinux127@lemmy.zip 13 hours ago
Your IP address is what they are after
They quietly compromise your system and then your IP gets used as a proxy for attacks against larger targets like government institutions
daniskarma@lemmy.dbzer0.com 8 hours ago
That doesn’t work that way.
IP addresses are fairly public.
In order to get that kind of infection there need to be a serious vulnerability. None of the services I expose have those kind of vulnerabilities, and I keep them updated.
A Zero-day may be possible, but it can happen with any software.
Any way, even if Some of my services got infected that way. I have them all in docker containers. If the managed somehow to insert any malicious software it would have disappeared in the following restart of the container.
And in order to have a software that breaks out of the container it would need to also have some sort of zero-day docker exploit. Two zero-days needed for accomplish that…
Every expose software I have is running on a caddy reverse proxy. And caddy is the only authorized author on my firewall so it gets more difficult to try to run an unexpected malicious software.
dogs0n@sh.itjust.works 15 hours ago
If you are talking about brute force attacks for your password, then use a good password… and something like fail2ban to block ips that are spamming you.
This point doesn’t exactly match, but: public services like google auth don’t require users use vpns. They have a lot more money to keep stuff secure, but you may see my point… auth isn’t too trivial of a feature to keep secure nowadays. They implement similar protections, something to block spammers and make users have good passwords (if you dont use a good password, you are still vulnerable on any service).
possiblylinux127@lemmy.zip 13 hours ago
The password is totally irrelevant for the most part. The worst case is that they get access to the dashboard
The problem is when major security vulnerabilities are found like remote code execution