6 ms·

I have a dedicated server with encrypted partitions and admin backdoors turned off at ovh. So theoretically they shouldn't be able to access the running system,

I have a dedicated server with encrypted partitions and admin backdoors turned off at ovh. So theoretically they shouldn't be able to access the running system, and if they take it down to access the partitions directly, they're encrypted so that won't work either.

dualboot 13y ago
The right answer. With a design that focuses on simplicity ( reducing the entry points ) you can be pretty well assured that if someone attempts to gain access to your data you will likely know. 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.
- etherael 13y ago
  That said, even with a dedicated server, I still use gmail, because https://github.com/etherael/phoneme https://github.com/etherael/phoneme
Sami_Lehtinen 13y ago
That's why they take memory snapshot first, which is trivial with VPS and then pick encryption keys from it to access encrypted volumes. This is well known method and works with pure hardware machines too with physical access. It's great question when you get to server, to shut it down or leave on. If on, it could destroy data, if turned off encryption keys are gone. I think it would require some individual case analysis before deciding which one is better approach.
- etherael 13y ago
  Isn't the pure hardware method for memory snapshots some ridiculously complex mechanism with freezing the memory and quickly transferring it to a reading device? 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.
  - lloeki 13y ago
    > Isn't the pure hardware method for memory snapshots some ridiculously complex mechanism with freezing the memory and quickly transferring it to a reading device? With Virtual Private Servers, it's trivial to do the virtualized version of this through the hypervisor.
    - etherael 13y ago
      My original statement said "dedicated server". The response said; "virtual server attack, also works with pure hardware machines". The only version of this attack that is relevant to the original statement is one that works on a dedicated server, so re-stating that it's trivial to do this against a virtual private server isn't really adding anything to the conversation.
  - mike-cardwell 13y ago
    "ridiculously complex mechanism" ... Not really. Anyone with the ability to stick a USB stick in a USB port and hit a power reset button can pull off this attack: http://www.mcgrewsecurity.com/tools/msramdmp/ http://www.mcgrewsecurity.com/tools/msramdmp/
    - etherael 13y ago
      Interesting stuff. TRESOR might not be overkill after all.
    - noinsight 13y ago
      Hmm, that requires USB booting though, if you disable that from the BIOS and password protect it, they can't really use this method. If they pull the battery the machine needs to be turned off and so the RAM will clear.
      - etherael 13y ago
        You don't get BIOS access to low cost dedicated servers on OVH, even though they're dedicated, you can't KVM them. 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.
- oijaf888 13y ago
  How do you do that with a pure hardware machine with physical access without rebooting the machine? Even if you freeze the memory with liquid nitrogen and extract the data from it, that process results in the server needing rebooted afaik. Obviously I'm assuming there's no 0-day you can just enter in via the serial console or similar.
  - e12e 13y ago
    You might chill the RAM, reboot, read out the encryption keys, mirror the disks, verify that you can decrypt it -- and then leave the server off -- mail the customer a notice saying the server rebooted due to a power glitch. 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.
bigiain 13y ago
Possibly some too-cynical questions… 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?
- etherael 13y ago
  > Do you think ovh is any less beholden to GCHQ than Google et al are to the NSA? 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
  - bigiain 13y ago
    Great response - thanks. 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"?)
oijaf888 13y ago
How do you handle reboots? If all of your partitions are encrypted I would guess you use a serial console to enter in the encryption password to decrypt and mount the actual OS drive?
- etherael 13y ago
  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.

dualboot 13y ago

The right answer. With a design that focuses on simplicity ( reducing the entry points ) you can be pretty well assured that if someone attempts to gain access to your data you will likely know. 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.

etherael 13y ago
That said, even with a dedicated server, I still use gmail, because https://github.com/etherael/phoneme https://github.com/etherael/phoneme

Sami_Lehtinen 13y ago

That's why they take memory snapshot first, which is trivial with VPS and then pick encryption keys from it to access encrypted volumes. This is well known method and works with pure hardware machines too with physical access. It's great question when you get to server, to shut it down or leave on. If on, it could destroy data, if turned off encryption keys are gone. I think it would require some individual case analysis before deciding which one is better approach.

etherael 13y ago
Isn't the pure hardware method for memory snapshots some ridiculously complex mechanism with freezing the memory and quickly transferring it to a reading device? 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.
- lloeki 13y ago
  > Isn't the pure hardware method for memory snapshots some ridiculously complex mechanism with freezing the memory and quickly transferring it to a reading device? With Virtual Private Servers, it's trivial to do the virtualized version of this through the hypervisor.
  - etherael 13y ago
    My original statement said "dedicated server". The response said; "virtual server attack, also works with pure hardware machines". The only version of this attack that is relevant to the original statement is one that works on a dedicated server, so re-stating that it's trivial to do this against a virtual private server isn't really adding anything to the conversation.
- mike-cardwell 13y ago
  "ridiculously complex mechanism" ... Not really. Anyone with the ability to stick a USB stick in a USB port and hit a power reset button can pull off this attack: http://www.mcgrewsecurity.com/tools/msramdmp/ http://www.mcgrewsecurity.com/tools/msramdmp/
  - etherael 13y ago
    Interesting stuff. TRESOR might not be overkill after all.
  - noinsight 13y ago
    Hmm, that requires USB booting though, if you disable that from the BIOS and password protect it, they can't really use this method. If they pull the battery the machine needs to be turned off and so the RAM will clear.
    - etherael 13y ago
      You don't get BIOS access to low cost dedicated servers on OVH, even though they're dedicated, you can't KVM them. 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.
oijaf888 13y ago
How do you do that with a pure hardware machine with physical access without rebooting the machine? Even if you freeze the memory with liquid nitrogen and extract the data from it, that process results in the server needing rebooted afaik. Obviously I'm assuming there's no 0-day you can just enter in via the serial console or similar.
- e12e 13y ago
  You might chill the RAM, reboot, read out the encryption keys, mirror the disks, verify that you can decrypt it -- and then leave the server off -- mail the customer a notice saying the server rebooted due to a power glitch. 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.

bigiain 13y ago

Possibly some too-cynical questions… 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?

etherael 13y ago
> Do you think ovh is any less beholden to GCHQ than Google et al are to the NSA? 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
- bigiain 13y ago
  Great response - thanks. 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"?)

oijaf888 13y ago

How do you handle reboots? If all of your partitions are encrypted I would guess you use a serial console to enter in the encryption password to decrypt and mount the actual OS drive?

etherael 13y ago
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.