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
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
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.
So? Pubkey login only and fail2ban to take care of resource abuse.
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:
https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server
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
Are you giving random strangers legal permission to pentest you? That’s bold.
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.
Plot twost, That it’s neighbor ip
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.
🤔🤔🤔🤔🤔
https://arstechnica.com/information-technology/2022/02/after-lying-low-ssh-botnet-mushrooms-and-is-harder-than-ever-to-take-down/
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 yet you continue to talk about it as if it’s a single piece of software that has been reviewed and like all ssh shares the same vulns but the software is entirely different depending on who implemented it so you have no real clue what you’re talking about and it’s actually sad people will be misled by your nonsense and false bravado. (https://en.wikipedia.org/wiki/Secure_Shell)
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 @[email protected] 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.
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.
Sorry, misunderstanding here, I’d never open SSH to the internet, I meant it as “don’t block it via your server’s firewall.”
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.
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.