New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Keep them in ramdisk, if the machine is turned off noone will be able to recover the data. Even you.
On a more serious note, it could be encrypted. But then the encryption key must not be stored on the same server. So it cannot boot automatically, someone must supply the encryption key manually. Not sure if you want this.
If you want to be able to read them at some point in the future (de-crypt), you will never be able to ensure that no one is able to recover the data.
@rds100 's suggestion of ramdisk is your best bet.
I was thinking of grabbing password or keyfile with curl from somewhere else. But if this a viable solution for email (if the pw retrieval fails the mail server stack is NOT started) it's not for logs, because the machine need to log even if it's offline.
I will be able to recover the data because I know the password. Or the key. And if i lost them, or purposely delete them -NO ONE- must be able to decrypt the container.
It's the purpose of crypting data
@robocat for encrypting incoming emails do this: https://grepular.com/Automatically_Encrypting_all_Incoming_Email
For password on boot up of dm-crypted root on a remote machine/vps, you could do this: http://blog.nguyenvq.com/2011/09/13/remote-unlocking-luks-encrypted-lvm-using-dropbear-ssh-in-ubuntu/
Thank you @craigb, i'll check the second option!
I don't recommend the 2nd option for a remote vps - esp. one that needs to be up 24x7 (e.g. A mailserver). It's also easy for a motivated evil provider to backdoor the remote boot auth process
If you don't control the box and the box has access to the plaintext obviously it's game over.
I know. Admin interaction at boot-time is a pain in the neck. And provider is a weak point in vps enviroment.
But auto-crypt every email in gpg destroys one of the great features of imap: search function. And leave out in the clear lots of precious info.
We are in the search for a balance security-user friendliness. And with a VPS the security is limited by default (even with kvm).
Just a question: can a node owner browse on a ciphered kvm container when it's unlocked?
Maybe you're better off with a cheap dedi (better) or colo your own box (best)?
Yes Craig, options evaluated. But there isn't such things like "cheap solutions" in interesting locations besides vps. Add money to the equation security-user friendliness
@Robocot
mKS Kimsufi 2G for £10/month?
France or UK or Canada? I'm looking for free speech countries like Iceland or Switzerland. I'm in Europe, so i can't look too far from here.
@robocat let's back up a little..what's your budget and what threats are you trying to protect against? Also how comfortable are you with Linux hardening?
I am using this method on a server and it is pretty simple. Squeeze does it almost automatically. I never had any problems. You usually know when your server will reboot and you can decrypt it manually over ssh. And nobody but you can decrypt it.
Of course a motivated admin with physical access could always do something but you can make his job more complicated by disabling all local logins, local access, disabling USB, serial port and any other ... what else could be disabled?
Do not forget to disable disk fsck etc because that could stop boot process waiting for you (local) user to click on enter. Easiest way is to use tune2fs and touch /fastboot.
You should also encrypt whole disk if you want to be sure. Split the disk in partitions and use different keys. /boot is not encrypted and you should do a md5sum of all files in /boot and compare them to saved checksums to be sure that nothing was changed. You can do that with a simple shell script which is started from rc.local.
did I miss anything?
@komo good to hear you are having success with it. I was tempted to go that route but 2 things held me back. The first is that host nodes reboot sometimes without warning and I may not be online to handle the pw entry (so website/mailserver down) and secondly how easily it can be defeated (backdoor /boot). I think the first could probably be handled with redundant services and simple service availability checks. It's the second issue that is more problematic. A nefarious admin can use a backdoor'd /boot to read all the files anyway (or spawn a shell or whatever).
I do think this method makes casual snooping through files harder so if that's the goal then I'm on board with it. But once an evil admin decides to take an active approach, all bets are off. The real problem here is that detecting this kind of attack is really hard - I'm sure you've considered the pitfalls with the md5sum approach.
Ultimately, this is why I think it comes back to stating what threat actors/goals we're concerned about to better frame the convo.
I was talking/thinking only about dedicated server.
That's why you should do two things which are connected to each other.
First, split disk in multiple encrypted partitions. root partition will be decrypted on boot, other data partition(s) like /home should be decrypted manually (and not through /etc/crypttab) but only if second point (see below) finished without errors.
Second, compare checksum of all files in /boot with saved checksums (which are created and saved last time you upgraded kernel). If any of the checksums are not same you should not continue. You should als save first 512 bytes of /dev/sda (dd if=/dev/sda of=/root/dd-sda bs=512 count=1) and also compare these.
This (2nd point) can easily be solved by a small shell script which is run on boot.
If there were no errors you should probably (I maybe missed something) be safe to mount /home and other partitions like /var/mail.
Don't forget, if Evil Admin has access to the hardware your server is running on, be it physical or virtual, its possible to pull the encryption keys from RAM once the system is running.
My purpose is keeping private my private things. I dislike data retention and any sort of filing or data mining. I'm not running a mob syndicate, but i want to send an email to my brother with personal information free of any mass monitoring project.
My ideal budget if 5 euro/month and i found a Iceland KVM offer from edis to be ideal.
Basically i want to encrypt the drive because i don't know who handle the hard disk when the machine is down. It's bad to know that your data is in clear, somewhere, and you can't do anything to protect yourselves.
I know that you can freeze the ram and analyze it to recover password, keys and whathever, but if someone is motivated enough to put my server in the fridge he deserve to win. I can't fight with this kind of enemy.
Craig, what do you think? Am i wrong about it?
It's very interesting. Do you know some reliable debian howto or do you care to write one?
I'm not sure it suitable to a KVM container but is precious knowledge nonetheless.
If you're just worried about email confidentiality, why don't you encrypt/decrypt the emails on the local machines? I think you can use GPG for that, and then you don't need to worry about a compromised server. Of course, you could always encrypt the server as well, there's no kill like overkill!
Keep in mind that the vast majority of emails are sent over SMTP - port 25, unencrypted.
I could write a howto but I did this stuff with a dedicated server, not with a virtual server like KVM/OpenVZ.
It is easy if you are able to boot your server in some kind of netboot. If not you will have to do everything on your running system which is complicated. EDIS have in their admin panel some kind of rescue boot. Or you could boot in any other live system without mounting your disk.
After booting in this rescue/live system you should partition your disk and encrypt partitions with cryptsetup.
Here is a video howto for a dedicated server but it should work in the same way with KVM:
I would recommend testing this with VirtualBox on your local machine.
@komo like the video! Back to the md5sums of /boot...what I was alluding to in my previous comment is that a sufficiently motivated evil admin can thwart your file integrity checks through either manipulating your md5sum binary or the kernel such that when the checks are run, the output is manipulated. The evil admin knows what md5sums to feed you as /boot is sitting there in plaintext... It's a chicken and egg situation...
Essentially this boils down to the fact that unless you use Trusted Boot tech, you can't make provable claims about the integrity of a system you don't physically control. I'm definitely not suggesting that what you are doing doesn't have value but as with any security control, it's important to understand its limits.
@robocot given your concern about the potential for offline data leakage or data snooping, then going with crypto makes sense. As you indicated earlier you're trading security and convenience. Its either file based (as per grepular link shared earlier), home directory based, or the file system level. To protect your mail spool, don't leave it on the box. Shuffle it off every X minutes to a system you do have physical control of...