Re: Central Backup Server
Miek Gieben <[email protected]>
| Newsgroups | gmane.comp.sysutils.backup.hdup.general |
|---|---|
| Message-ID | <[email protected]> |
[On 27 Jun, @16:44, Nathan wrote in "Re: [hdup-user] Central Backup ..."] > On Fri, 2003-06-27 at 01:29, Miek Gieben wrote: > > > This dd command is a good one, I'll add that to the FAQ. The other idea > > is to use "virtual" users for the backups? > > Virtual users in a e-mail style sense isn't really possible. It is a > very good idea to use separate normal users in this case. If you use one > user for all backups then the cracker only has to break into one account > and then all the backups can be deleted, or at least read(This is where > encryption helps, but doesn't save you if the cracker got the key from > the server already). Restricting the users involved as much as possible > is your only choice. yes, I absolutely agree with you. > > why does chattr +i help? Reiserfs is doesn't even have chattr :( But when > > somebody is root on a machine - nothing can save you. The only thing you will > > be able to do is make the time it takes to completely destroy your system as > > long as possible. Chattr falls in to this category. > > With my setup if a cracker has broken into the a server they have easy > access to the backup server, but only as the username for that server. > The chattr prevents them from going over and removing the backups when because they are not root no the central backup server? But if they were root on that server, chattr would help? > > that is probably always a good idea. Making hdup itself work in a chrooted > > enviroment is probably worth the effort to research it. But your backups > > will also be in this chrooted area.... > > Yes, I plan to come up with a easy as possible chroot setup after I > figure out an easy restore procedure for my setup. ok, great! Let me know when you have figured it out. I'm going to be fairly busy the coming weeks, so I doubt I have any time to look into this issue... :( > > instance encrypting to stdout with a symmetrical key (which should be read from > > a file) is not possible. Ideally pgp should work as mcrypt but than with key > > pairs. > > The goal with gpg isn't to to use a symmetrical key. If it is a > symmetrical key then it can is vulnerable on the server if someone gets > in. With public/secret key pairs(what gpg/pgp is all about) the public > key can encrypt the backup, but can't be used to decrypt the backup. The > secret key can be kept secure by not having it on any servers. In my > case I would put them on a usb pen drive. I would plug in the drive, > mount it, and have hdup read the secret keys from the pen drive. Plus > you could also have a passphrase on top of the secret key. Since > restores would be a manual process. So someone could steal the pen > drive, and they would still need your passphrase. Yes, I know how public key encryption works :) But because of the fact that you now have to deal with 2 keys (pub and priv), it's more difficult than mcrypt. Using a passphrase will ofcourse also collide with running hdup from cron - I still need to think about these issues. > When I was looking for a good backup program I ran across one that used > gpg, so I am pretty sure it can work. > > Here is one, http://freshmeat.net/projects/duplicity/?topic_id=137 > > Here is another, > http://freshmeat.net/redir/netbackup/19607/url_tgz/wiredbackup.tgz > > Here is the one I first saw, > http://www.opennet.ru/dev/fsbackup/index_eng.shtml well, I they have it, hdup should also have it :)) grtz Miek -- :wq!