If you're going to pull this, you need to know in advance that it's necessary, that's not some minor thing that everyone is going to just do automatically, it's an extra, complicated step it's easy to screw up.
That said, I acknowledge the possibility of compromise in the aforementioned scenario, but once again I don't understand people who always jump to the "I am vulnerable to this narrow threat model, ergo, I should not bother to protect myself against any threat models". Especially when the measures you can take to protect yourself most likely will address the actual threat models you are liable to encounter.
mid to high range ones you can though so that might be a workable solution there.
Also, they can still rip the ram out and nitrogen it.
With Virtual Private Servers, it's trivial to do the virtualized version of this through the hypervisor.
At this point you have pretty much everything on hand to help you fool the customer into believing everything is ok (eg: replace the whole physical machine with a vm...).
Come to think of it -- if you know the hardware in the machine, you probably could replace the machine with a vm anyway -- just mirror the disks and go.
For me that is an important factor. I rather dislike the fact that in scenarios like Gmail and other providers of their ilk -- access is provided transparently to a third party.
Running your own server can give you a reasonable expectation of privacy. Even in a hosted/colocated environment if you take the time and effort.
Do you think ovh is any less beholden to GCHQ than Google et al are to the NSA?
Do you think your encrypted partitions and turned-off admin backdoors protect you much against people with physical access to the hardware?
OVH maybe a little more, because at least they're not under the direct auspice of the most megalomaniacal state in the world and will act according to their economic incentives in being a reliable and trustworthy service provider, which in a purely free market would align their interests with my own. However being as they are subject to various hostile state entities that have the ability to exert deleterious effects on that self interest, to the extent that they are forced to, they will cooperate with those entities.
I take action to protect myself from those threats to the greatest extent that I am able in either scenario whilst acknowledging that every theoretical threat model can never be entirely negated, coupled with the fact that at the end of the day, bothering to break through all of my measures and taking that trouble, they would find basically nothing that they were interested in.
I despise the state, sure, I'd like to see it dissolve into something like the system outlined in the machinery of freedom, sure. However in my view, taking any violent measures to expedite this process would both make me as bad as the enemy, and compromise the goal of a better world even if it actually contributed to the downfall of the state.
> Do you think your encrypted partitions and turned-off admin backdoors protect you much against people with physical access to the hardware?
"Much" more than non encrypted partitions and not turned off admin backdoors? Absolutely. Completely and utterly impenetrable to any attack by any means at all? Not likely, I can think of one off the top of my head that would work; freeze the memory, get an image, power off the system and extract the encryption keys from the image to re-mount the partitions. That's 1) not automatic 2) not easy 3) easy to screw up 4) not undetected
Another question - have you done the thinking or got some advice about whether marginally trusting a potentially subvert-able hosting company in a jurisdiction you don't particularly trust (US, UK, and unfortunately for me, Australia) is likely to be a better or worse bet than trying to source a server/vps in a more trusted jurisdiction? (perhaps Iceland? Or am I fooling myself assuming there's anywhere "trustworthy"?)
I think of it like trusting gangs in the thieves guild, there might be some gangs that are ethically more admirable than others, but at the end of the day if it comes down to it, the administrative board of the thieves guild is able to compel any of it's member organisations to act in accordance with its edicts.
So if you're going to take any action that might cause the administrative guild of that thieves board to attack you, it should be a foregone conclusion that the trust of intermediary parties beholden to that central authority is irrelevant.
Arrange your affairs accordingly. If you must deal with gangs of thieves, deal with the better ones, and if you can avoid it, don't. And if, heaven help you, you decide to take action that will paint crosshairs on your back from the central thieves guild committee, your opsec should take into account the full powers that committee is able to bring to bear upon you.
Assuming however it could somehow be pulled off; I guess potential ways to mitigate would be to keep a copy of the exact hardware characteristics of the system you originally have, kernel log on bootup, precise size of disks, chipsets of all the various controllers and compare when the system reboots. It would however be possible though extremely hard to get an exact duplicate of all of these at the virtualisation layer level.
You could call the virtualisation layer in the cpu requesting access to virtualise a subsystem, clock the data bus speeds... There should be some overhead from virtualisation that wasn't there when dedicated...
It's an interesting problem. I'll think more about it.
As for time needed, assume this: The attacker sets up a physical server that can accept the same physical disks as your server (with hotswap), with an additional disk (or ssd) for booting into a hypervisor, sets parameters for this hypervisor to closely mirror that of your server. The attackers server would typically be faster than yours -- it is/can be bought some time after your server was, so this should almost be universally possible.
The attacker boots the vm server, sets everything up; then kills power to your machine, moves the disks over. Your downtime: the time it takes to move the disks (literally).
Good luck differentiating between this and legitimate downtime.
I still think reading the encryption keys from RAM after cooling them with some co2 would be the more likely attack, but it's a fun thought experiment...