On Thu, 23 Apr 2015 08:36:32 AM Noah O'Donoghue wrote: > I have a few cases where I'd like to encrypt without taking the system down > for extended periods, ie, servers. > > In the windows/apple world truecrypt / bitlocker / filevault will all let > you encrypt the root partition as a background process, throttled to a low > IO load. Usually this requires a reboot to get started, then runs in the > background. > > Does anyone know how to achieve this in the Linux world? (preferably with > luks)
LUKS doesn't permit doing per-file operations because it operates on the block device. However any real server should have RAID-1. So you could break your RAID-1 array, apply LUKS to one half and then re-mirror. Then you break it again apply LUKS to the other half and re-mirror. No down-time as long as you don't have a disk error during the process... A more cautious way of doing it is to replace one of the internal disks with a USB attached external disk so you can replace each disk with a LUKS encrypted block device without ever having less than 2 running disks. USB is slower than SATA but you just wait a while as it all happens in the background. On Thu, 23 Apr 2015 05:18:10 PM Daniel Jitnah wrote: > Not sure what you are trying to achieve. But if it is protecting system > files from unwanted/malicious modification, then encryption is probably > not the way to go. Imagine if a persistent attacker actually managed to > change the encrypted data: It would be a much worse result, as you could > be unable to de-crypt and access everything!! We had a discussion on this list about someone who had their NAS compromised in such an attack. The fact that they hadn't used encryption on the NAS in the past didn't stop the attacker from doing a background encryption of all the files and then asking for a ransom. NB before anyone says "Noah could solve the online encryption problem with the same software that the hackers used" please note that by definition attackers aren't too bothered about the risk of losing data, so the quality of the code is probably much lower than that which you would willingly trust with your data. > Even if it did not, it > may well be that a change may not be detected until it is too late. So > to handle this I would suggest using proper intrusion detection > software, design for the purpose, eg: Tripwire. Its better that you > know that an attack has taken place and you can react accordingly, than > you believing that you are secure (falsely) and an attacker somehow > finding its way in and you not knowing about it. Tripwire is easy to fool. Sure it can do some good (I've had one of my systems compromised by a trojan that was caught by debsums and would have been caught by tripwire) but I wouldn't rely on it. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
