Central Backup Server

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
server and then they can login to any of the servers that backup to it.
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.

   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.

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

  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.

Any ideas of how to improve on this?