hi,
You can use plain ssh and create an unpriviledged user to store the backup files, I normally do something like this with ufsdump which obviously won't work on suse but tar should be ok as well:
tar -czf - / | ssh -l <user> <host> 'dd -of=backup.tar.gz'
But i would still like to stick to rsync, cause it has the delete and replace feature. So i dont have to tranfser the whole archive each time.
(check syntax first, out of head and head isn't fully patched at the moment + infected with a trojan that is now compromising stomach as well, hate colleagues so trying bio warfare by working anyway)
-- Ronny Martin
-----Original Message----- From: Mario Ohnewald [mailto:mario.Ohnewald@gmx.de] Sent: Thursday, December 04, 2003 10:32 AM To: suse-security@suse.com Subject: [suse-security] Secure Backup
Hello! I have two boxes and want to save a backup of each others on it. So far i have created a ssh key for both machines so i can make a ssh rsync to each other. But the terrible sideeffect is that IF one of those boxed get compromized the cracker will be root on both of them!!!
My Backup script: #--- START --------------------------------------------------------------------- #!/bin/sh speed=500 verzeichnisse="etc home root boot usr/local/bin/"
for verzeichniss in $verzeichnisse do find /$verzeichniss -size +10200k | rsync -avvz --exclude-from=- --delete -e "ssh" /$verzeichniss bortal.de:/backup/sts/ done #--- END -------------------------------------------------------------- -----------
I need to save it on each other because both have a 100MBit Internet connection which makes a restoring backup easy! So a tape Backup is not really possible. :/
Any ideas/hints?
-- +++ GMX - die erste Adresse für Mail, Message, More +++ Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.net
I use BackupPC as backup software and had to think about similar situation. Basically BackupPC does login via SSH (root) and starts tar on the remore host. I did not want to give the BackupPC user root permissions and i did not want to allow user BackupPC to run tar as root (just allowing him to run tar with certain paramaters). I came up with the following solution (should be easy to adopt to rsync): the first shell script is used as login shell for user backuppc, the second is the wrapper script that calls tar and ensures its only called with the right parameters (script looks complicated, but thats just due to the parameter processing for BackupPC). You need to configure sudo to allow the backup user to execute your wrapper script with root permissions. Hope this helps and gives you some ideas peace, Tom p.s.: i hope i dont do something very bad here, security wise. if someone finds something really crappy here, i would be glad if they let me know :) --->8------------------------------------------------------ #!/bin/bash # # Simple shellscript that is called as login shell # for the backup user. All it does, is calling the # tar wrapper script via sudo # shift sudo /usr/local/bin/tar-wrap $* --------------------------->8------------------------------ the backuppc user is allowed to call tar-wrap via sudo with root rights. #!/bin/sh # # client side tar wrapper for BackupPC # Patch of Tar.pm is needed to send "--exclude=name" as "name" # # 20th Feb. 2003: V1.0b, Thomas Seliger # - initial release # # PARAMETER DOCUMENTATION # ----------------------- # # $1 is backupmode (fbackup|ibackup|restore) # # $1 is backupmode (fbackup|ibackup|restore) # # if backupmode fbackup: # $2 is sharename # $3 - $* are the tar "--excluse=" excludes (last . ist omitted) # # if backupmode ibackup: # $2 is sharename # $3 is "--newer=" date parameter for tar # $4 - $* are the excludes (last . ist omitted) # # if backupmode restore: # $2 is sharename ############################################################################################ # Configuration Settings ############################################################################################ ALLOW_RESTORE="no" TAR_CMD=/bin/tar ############################################################################################ # Dirty Code ahead ;) ############################################################################################ case "$1" in fbackup) # Save sharename (Argument2) SHARENAME=$2 # Shift twice to have only the exclude arguments left shift 2 # Generate the --excludes for tar, but omit the "." EX_TEMP=$* EXCLUDES="" for DIR in $EX_TEMP; do if [ $DIR != . ]; then EXCLUDES=$EXCLUDES" --exclude=$DIR" fi done $TAR_CMD -c -v -f - -C "$SHARENAME" --totals $EXCLUDES . ;; ibackup) # Save sharename (Argument2), tar newer paramter (Argument3) SHARENAME=$2 NEWER=$3 # Shift three times to have only the exclude arguments left shift 3 # Generate the --excludes for tar, but omit the "." EX_TEMP=$* EXCLUDES="" for DIR in $EX_TEMP; do if [ $DIR != . ]; then EXCLUDES=$EXCLUDES" --exclude=$DIR" fi done $TAR_CMD -c -v -f - -C "$SHARENAME" --totals --newer="$NEWER" $EXCLUDES . ;; restore) if [ $ALLOW_RESTORE=yes ]; then $TAR_CMD -x -p --numeric-owner --same-owner -v -f - -C "$2" else echo Restore not allowed! exit 111 fi ;; *) echo No argument given echo Usage: tar-wrap fbackup\|ibackup\|restore param1 param2 ;; esac
if you really need the permissions etc., run on the target as root, log in unpriviledged on the source. on the source, you can even have a "forced command" configured for your ssh key. in case you for some reason really want to run as root on the source box, too, forced command is your best friend, since then the "attacker" only has access to the files, which he obviously has already anyways (at least to their most recent backup). man sshd .ssh/authorized_keys2 file format command='...' Lars Ellenberg
On Thu, 4 Dec 2003, Mario Ohnewald wrote:
tar -czf - / | ssh -l <user> <host> 'dd -of=backup.tar.gz'
But i would still like to stick to rsync, cause it has the delete and replace feature. So i dont have to tranfser the whole archive each time.
This is risky, as you don't keep any change history then. Imagine you erroneously modify some files the wrong way. If you don't immediately realize it and your rsync-backup runs, then these wrong modifications will also be applied to the backup. The correct version of the file will be gone for ever then. Better use tar and do incremental backups. (There is a reason why some procedures are standard everywhere.) -- Rolf Krahl <rolf.krahl@gmx.net>
How about duplicity? it offers incremetal backups, encrypted with gpg and stored via. ssh etc., just take a look @ http://www.nongnu.org/duplicity Regards, Sven PS: Sorry Rolf, i mixed the To lines...
participants (5)
-
Lars Ellenberg -
Mario Ohnewald -
Rolf Krahl -
Sven 'Darkman' Michels -
Thomas Seliger