[bitfolk] Re: Thoughts on tightening up Xen Shell's SSH (not yours - that's your business!)

Hi, Agreed. Yes: this is a worrying attack surface for sure. I'm sure there have been a few holes over the years but only this current attack and the ssh-1 break really stick in my mind as being major, major problems. So my feeling is that the track record is pretty good over the long term, even compared to other software in the same class. However, it's also true that as sshd gets bigger and bigger the attack surface slowly increases too. It would be a shame to have to hide the service behind some other service. It would be similar-but-different to the inconvenience of running sshd on a weird port (which I do for my machine, but is generally unacceptable for a public service for lots of reasons to numerous to include here). A few questions: Do you know how available different options such as VPNs, etc are from behind common firewall and NAT configurations? We know that HTTP(S) is available almost everywhere, and I imagine sshd is a close second. But lots of other services are frequently filtered by providers and I (for one) don't know the likelyhood of various other options being available in which places. Do you have a feel for whether people in general are starting to think that ssh is not suitable for direct exposure to the Internet? If this feeling is mounting then it's probably best to follow suit. Of course, there are always the risk averse who always use bastion hosts, but there has always been a hard-core of (especially) FOSS and academic people who have a risk profile that allows it. Do you have some more detail about the threat model you're trying to protect against? A suggestion regarding bastion hosts: (Just an idea for discussion; not really fully formed yet) Depending on the threat model, perhaps it's enough to provide an ssh endpoint that simply leads to a shell or environment that only allows a further ssh into the regular Xen Shells? That 2nd hop would still require the same auth as it currently does. The purpose of the initial auth would be to provide a DMZ. Even a full root compromise of that environment (for example, via the irregularly authenticated RCE exploit in the XZ backdoor) wouldn't get you any persistent user data or shell access. At worst the attacker would be able to sniff in-progress console sessions and collect credentials for some hosts and there are surely ways to monitor long-running connections to the bastion host via a router or firewall to detect successful attacks? Ooo! Don't run ldd on an untrusted binary. :-p https://jmmv.dev/2023/07/ldd-untrusted-binaries.html :-) Best wishes, @ndy -- andyjpb(a)ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF