Re: Central Backup Server

[On 27 Jun, @01:57, Nathan wrote in "[hdup-user] Central Backup Ser ..."]
> Hello,
> 
>    The central backup server idea mentioned at the bottom of the howto
> is a bad idea. It means all a cracker has to do is break into the backup

First of all, thanks for your feedback.

> server and then they can login to any of the servers that backup to it.

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.

> Especially if a key without a passphrase is used. Even with keychain the
> cracker could pull the password out of memory. The only reason I can
> think of why you would want to have the backup server initiate the
> connection would be to be sure that backups were only attempted when the
> backup server was up. Why this would be critical to someone I don't
> know. Even if it was, I think the security risks would almost surely
> outweigh the reason.

This was purely, look this can be a use too. Keep everything central. 

>    The setup I use is a backup server with a system partition(/) and a
> data partition(/home). I setup a user on the backup server with the
> hostname as the username. I did run into a problem with the mail server.
> mail is a standard system username, so I setup a user called email
> instead. You could also run into other usernames like news with the same
> issue. I would prefer using the hostname with domain, but adduser
> doesn't didn't accept them. I don't give the users on the backup server
> passwords. Then I generate a dsa ssh key with no passphrase on each
> server as root. I then transfer the public key to the backup server with
> scp, and set it up in /home/hostname/.ssh as authorized_keys. I use
> mcrypt to encrypt the archives with rijndael-256. I use dd
> if=/dev/random of=secret_key bs=32 count=1 to generate a random 32
> character key for mcrypt.

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?

>   My way does allow anyone with the dsa key for a certain server to
> login as the server's user on the backup server. But to get the dsa key
> they have to break into the server and get root access. This would also
> give them the ability to delete the backups if I didn't run a cron job
> as root on the backup server to make the backup files immutable with

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.

> chattr +i. Since the cracker at this point has the secret used to
> encrypt the data it would be ideal to also make the data unreadable
> along with chattr, but that would prevent incremental backups from
> working properly. Keychain would make life a little tougher for the
> cracker, but having to worry about server reboots isn't for me. There is
> also still the risk that once the cracker has gotten in they can then
> use a local exploit to become root. To at least reduce this risk it is
> best to chroot the users to their home directory. Other ideas are either
> a restricted shell that would only allow the commands necessary for
> hdup, or rewrite hdup so that it can be set as the shell these users. It
> is also a good idea to in general harden the machine reducing the number
> of daemons and uninstalling unnecessary software.

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

>   One suggestion I have given Miek is to use gpg. This would make it
> easier to get hdup going since gpg is included much more often than
> mcrypt in distributions. It could also improve security in that gpg
> could encrypt the archives with the public key. Then the secret key
> wouldn't need to be stored on the server. It would just need to be
> accessible to the backup server when restores were being done.

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.

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

grtz  Miek


--
:wq!