Backup
Things I do not like about EFS and a better solution called Truecrypt
by Greg on Feb.19, 2007, under Backup, Security, Windows Server, Windows Vista, Windows XP
I am not expert on these things (encryption), but I have done some reading and found some issues with Encrypted File System I don’t like. I may not describe the issues correctly, so this is just my opinion more than anything.
1. In Windows 2000, don’t even bother. It can be bypassed with their recovery agent or administrator. So if you lose your laptop, the data can be accessed.
2. In XP, it is better and more secure. I think there is no data recovery agent, but I think a local administrator account on a non-domain install of XP will still have the private keys.
3. The private keys are on that hard drive!
4. You still see all the files. The file names are all viewable, and that may be a security risk for some companies. It’s better than nothing, but I don’t like that too much.
5. You can’t encrypt the whole system. Or a whole partition for that matter. You must encrypt a folder, and at that, only the files in that folder are encrypted.
6. Here’s the one I like least… with EFS, when you open a file, it is decrypted to a tmp file. This file is deleted once you finish with it, but as you know, files are not “wiped” from the drive when they delete, they just remove the pointer to it. So unless data is overwritten in that place of the drive, that data is accessible to anyone. If you had a spreadsheet with SSN’s or credit card numbers, and you just happen to lose your system to someone who knows what to do with it, you got a big problem!!
7. There’s more, I just can’t think of them.
Anyway, after doing some reading… I found that Bitlocker in Vista will be a very nice solution. But you have to buy Enterprise or Ultimate versions of Vista to get it. Bitlocker can encrypt the entire OS partition. Now that is nice! That is exaclty what we wanted! And if you set it up correctly, using a key or PIN at boot, it will make an extremely secure setup. One drawback, you can only encrypt the partition the OS is on, not other partitions. You’ll need to use normal EFS for them.
That’s nice, but I have Vista Business. And I don’t want to spend more money right now. Plus, on my main system and pretty much all my clients, they have 2000 and XP. Guess what I found to get me by? TrueCrypt. www.truecrypt.org. Nice product!! And it’s open-source and free!!!!
With TrueCrypt, you can password protect an entire partition with AES 256-bit encryption. You can use multiple ciphers and even key based access using a USB drive. (Bitlocker can do the USB drive thing too!) It’s a tiny program running in the systray. And in my case, I am just running a password authentication and 256bit AES on a separate partition, so my performance is pretty good too, though not as fast without encryption. Now, with XP I will be making redirections to My Documents to that private drive, and saving all my “work-in-progress” there. That, to me, operates reasonably, and pretty darn secure. I could do more to secure it, like use a key file on my usb key drive. Then you cannot get into any of my private data without the key drive inserted! But I need to test that first.
TrueCrypt can also create a virtual drive from a file.� That might be handy, but performance is just a little slower that way.� It cannot encrypt your OS partition though, which is a drag, but at least I can encrypt a separate partition and you cannot see the file system structure.� It has a lot of neat features. Definitely worth trying if you want lock down things.
Remote ssh rsync linux backups with certificates and no passwords
by Greg on Oct.25, 2006, under Backup, Linux, Scripting, Security
Uber quick howto: (based on Debian)
1. Make sure ssh, rsync and sudo are installed and working.
2. Add a user account, on remote system.
2.a Add a certificate with openssl or ssh-keygen (look that up elsewhere)
2.b Make sure the cert is unencrypted with no password. Yes, that is a slight security concern, HOWEVER, if you are very careful to secure that private key, you are ok. In other words, don’t share it or let it out!
2.c Add your public key to your new users /home/username/.ssh/authorized_keys file. (how to’s for this stuff are on the web)
2.d Test this user’s login and make sure it logs you in from your local machine.
3. Now, this new user is unprivileged, so you need to use sudo for running the remote rsync command. Add this to your remote machine /etc/sudoers file:
nameofnewuser remotemachinename=NOPASSWD:/usr/bin/rsync
Above, you replace with the appropriate names.
4. Copy your private key from the remote machine and save it on the local machine where you will be backing up to. For example, save it in the local user’s .ssh directory. /home/localuseraccount/.ssh/private.key
5. You need to create a script. In the example below, I have an exclude.txt file also, so I can exclude directories and files. Look that up in the rsync how-to’s.
#!/bin/bash
rsync -avz --rsync-path="sudo /usr/bin/rsync" --exclude-from=exclude.txt -e "ssh -p 22 -i /home/localuseraccount/.ssh/private.key" remoteuseraccount@remote.server.com:/ /backup/to/path
In case you didn’t catch that, the section above with the rsync command is all one line!