Re: Central Backup Server

On Fri, 2003-06-27 at 01:29, Miek Gieben wrote: 
> Well, I don't think such a central backup server is a bad idea. What is a
> bad idea is to use normal user accounts for the backups. (Well I do it to...)
> You have seen question 10 in the FAQ? 
> 
>    Q10: Can I restrict access even more?
>    (Contributed by Boris Goldowsky)
>    A: Yes, you can, SSH allows you to do the following. In your
>    authorized_keys2 file, add the something like this:
>                                   _______
> 
> from="IP ADDRESS",command="/usr/local/bin/hdup -c /etc/hdup.conf remote HOST",
> no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-rsa
> AAAAB3NzcC1y.....
>                                   _______
> 
>    Where IPADDRESS is the address from which you connect, it can contain
>    wildcards: 10.0.0.* is valid.
>    And where HOST is the host you're backing up remote.
> 
>    If your key is now compromised they can only use it to run 'hdup'
> 
> 
> Although I see the point you're trying to make I don't think the reasening
> is logical to me. You're saying: please be carefull because if (when?) you
> get hacked they can hack other machine too (with this setup). Well if your
> backup server gets cracked you have serious problems already. If I were to
> be a system admin and this would happen, then all the clients with their
> backups on this system would be suspicious already (unless you know absolutely
> certain that no backups were ever restored to this client).
> 
> On the other hand you don't want to make it to easy for crackers.

When I said central backup server I meant it in the sense of it
initiates the process in some way. That is what I think is a bad idea.
Having a central machine for backup storage is less than ideal, but is
reasonable. In my case the backup server is restricted to by ip address
by the firewall. If they are get behind the firewall they still need the
dsa key.

> 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.

> 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
the backups would be most critical, after someone had broken in and
potentially used rm -rf /. Personally I use ext3 which is standard on
RedHat. I was just describing my setup. Hopefully there is something
similar for reiserfs. I am considering switching to it when it gets a
data=ordered style mode instead of only data=writeback.

> 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.

> I've looked at pgp (gpg) yesterday. And it is way different than mcrypt. For
> 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.

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

> > Any ideas of how to improve on this?
> 
> Again thanks for your comments. I could add some general security tips in the
> hdup documentation, but I also think it doesn't really belong their. Hardening
> your machine, using a firewall, picking strong passwords - people should always
> do that - but alas most people won't sacrifice easy of use for security.

I was thinking of more ways to improve the security of the backup
process. The greatest weakness is that the someone could ssh over from
one of the servers, and then go from there. I just thought of another
idea. Give each server it's own virtual server on the backup server.
Then if they get more access they are stuck in a complete jail. From
what I know of a certain piece of software for chrooted virtual servers
it could actually make the setting up of the jail less painful. One of
the problems with chroots is you have to copy everything necessary into
them. If you give the user a whole virtual environment you can just
mount -o bind everything necessary in, and one of the patches included
allows you to mount the binds read-only, even when the original mount
isn't read only.

The virtual server idea would be more complex and resource intensive,
especially the more servers you backup to one backup server.