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

Hi, That's quite a broad, unknowable attack surface tho', and perhaps the reason this thread has become quite bushy already. :-) I guess you're primarily trying to protect things in roughly this order: + Bitfolk business info such as customer lists and billing details + Customer data you have persistently on disk + VM state in memory + Customer credentials + Use of compute resources by people who are not customers + Use of other resources by people who are not customers Given that the XZ backdoor shows signs of having had a lot of resources, both technical and financial, and the exploit itself was carefully written so that only the holder of the private key could use it, it seems that, in that instance, your vulnerability may have been mostly to the last two items on the list. i.e. someone selling your machines as part of a botnet or using them for some purpose unrelated to Bitfolk. If it was a nation state, (I assume) it's unlikely you would be a general target for the earlier items on the list. Perhaps some specific customers in certain circumstances. But (IMHO) if the XZ backdoor was a nation state funded thing then it smells more like the bad end of the stuxnet situation where someone is trying to get a backdoor into a very specific installation for a very specific reason. Once the backdoor is in, they can use other hosts to hide the origin of their connections to the target. </wild-speculation> If it was a well funded private attacker then sure, they'll probably hoover up everthing they can get but there's still a lot more analysis to do here. Is it ransomware? Is it data mining? Is it resource usage for sale or for crypto-currency mining? Is it as a more anonymous jumping off point for more specific attacks? Deliberate zero-days cost a lot and provide specific capabilities. Accidental ones are probably more relevant to our discussion. The history of them suggests that they are patched quickly (in the kind of daemon software we are talking about) and often fragile or difficult to exploit. So perhaps other sandboxing or hardening techniques for the ssh daemon are appropriate? Of course, I can only speculate on your priorities but I think it'd be valuable to discuss the threat model in more detail because there is potentially a bunch of options (such as sandboxing or hardening) that can mitigate many vectors and won't change the workflow much (if at all) for customers. What do you think? Best wishes, @ndy -- andyjpb(a)ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF