Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@Condor generally that the harddrive cannot be imaged. as long as you encrypt the memory a server can be pretty close to unbreakable besides maybe a keylogger
-
@Condor The vm itself was encrypted, not the main harddrive :)
-
@Condor It helps protect customer data. One wouldn't need to be physically present to enter a LUKS key if the TPM implemention in Linux was up to date. There is another method with dropbear and busybox but that is also a hassle. @linuxxx Regarding remembering passwords... I use a local password manager (encrypted with gpg key) to store generated passwords so forgetting LUKS key is unlikely (I have done so before and never again).
-
@Condor As far as I know, you cannot clone encrypted hard drives with some cryptos. Truecrypt for example wasn't cloneable, I don't know about LUKS though.
-
@MateTea42 I would also like to add that there is no such thing as perfect security but one can make it damn hard for an unprivileged person to access data with the right security practices.
-
@PrivateGER LUKS writes a header to disk meaning that you could clone the disk and access the data with the right key. If I remember correctly truecrypt had the possibility of plausible deniability through creating a partition with an unidentifiable header. With LUKS you can also remove the header on creation an store it somewhere else. The trick is that you can clone all data as they are stored bits but without the right partition header you shouldn't be able to decrypt the data.
-
@MateTea42 Yup, that's what I meant.
-
@Condor unencrypted data doesn't touch the harddrive so it being unencrypted for the server to read/write doesn't matter in that case. as for authorized personnel that is the best case, 9 times out of 10 those people wouldn't care what is on it. there's always a chance that someone is there that would want to try to find something they could ransom. but there is a really slim chance of that happening.
in the case of cloud providers it is a good idea to do this if you don't want it to bite you in the ass cause it lowers the attack surface where the only access point to the data would be hacking the server while it's online, and at this point if you block everything with iptables and make ssh only connectable from an internal vpn connection the only attack would be through the forward facing applications themselves.
One:
Had a stack of harddrives with my important data, two USB drives and a 4.7gb disc, two or three cloud storage accounts.
Needed a restore:
Knocked the stack of hard drives onto the floor (all broken), stood on one of the flash drives, found the other one in a pocket of a pair of trousers which just came out of the washing machine, dvd too scratched to read and couldn't verify my cloud storage account because I lost the password to the connected email account and the backup email account to verify that one didn't exist anymore. Fucking hell.
Two:
Production database with not that much yet but at least some production data which wasn't backupped.
Friend: can I reboot the db machine?
Me: yup!
Friend: what's the luks crypt password?
Me: 😯😐😓😫😲😧😭
End of story 😅
For the record, the first one actually happened (I literally cried afterwards) and that taught me to update my recovery email addresses more often!
rant
wk98