4 ms·

small boot partition (basically enough to boot, get network, start ssh), all the actual data and /tmp on encrypted stores.

th0br0 13y ago
But do you validate that boot partition each time you reboot the system? How do you know that your computed hashsum (or similar) is actually the true one? ...
- etherael 13y ago
  got a hash of the boot partition, validate when it comes back up.
  - e12e 13y ago
    How do you know that you're not logging in to a vm, with all the data mirrored from your physical server?
    - etherael 13y ago
      This is reasonably clever, but how do you get a full disk mirror from a server you can't get into without powering off, if you do power off, the amount of time the system is down is a tipoff to the target as to what's going on. 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.
      - e12e 13y ago
        Please note that as soon as you've typed in the key needed to unlock the disk in the vm, your data is compromised. So any verification you attempt, has to be made from the unencrypted boot image... 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...
        e12e 13y ago
        Not sure if anyone will see this, this late, but someone else recently posted this presentation on Rakasha, a malware based on top of coreboot open bios and friends -- so if you know the type of server, you might just pop up the cover and switch out the BIOS...: https://www.youtube.com/watch?v=yRpilXPv8pU https://www.youtube.com/watch?v=yRpilXPv8pU

th0br0 13y ago

But do you validate that boot partition each time you reboot the system? How do you know that your computed hashsum (or similar) is actually the true one? ...

etherael 13y ago
got a hash of the boot partition, validate when it comes back up.
- e12e 13y ago
  How do you know that you're not logging in to a vm, with all the data mirrored from your physical server?
  - etherael 13y ago
    This is reasonably clever, but how do you get a full disk mirror from a server you can't get into without powering off, if you do power off, the amount of time the system is down is a tipoff to the target as to what's going on. 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.
    - e12e 13y ago
      Please note that as soon as you've typed in the key needed to unlock the disk in the vm, your data is compromised. So any verification you attempt, has to be made from the unencrypted boot image... 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...
      - e12e 13y ago
        Not sure if anyone will see this, this late, but someone else recently posted this presentation on Rakasha, a malware based on top of coreboot open bios and friends -- so if you know the type of server, you might just pop up the cover and switch out the BIOS...: https://www.youtube.com/watch?v=yRpilXPv8pU https://www.youtube.com/watch?v=yRpilXPv8pU