Date: Sun, 15 Dec 2002 20:44:22 -0800 From: Marcus Reid <marcus@blazingdot.com> To: Mike Tancsa <mike@sentex.net> Cc: freebsd-isp@freebsd.org Subject: Re: network backup Message-ID: <20021216044422.GA78227@blazingdot.com> In-Reply-To: <5.2.0.9.0.20021215195931.06955bc8@192.168.0.12> References: <bm3pvu06umktacjbt9g5vi0i7n6kkvtcfi@4ax.com> <20021213165625.GB91604@dan.emsphone.com> <mailman.1039802762.69058.fisp-l@lists.sentex.ca> <bm3pvu06umktacjbt9g5vi0i7n6kkvtcfi@4ax.com> <5.2.0.9.0.20021215195931.06955bc8@192.168.0.12>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 15, 2002 at 08:04:31PM -0500, Mike Tancsa wrote: > At 02:10 PM 12/15/2002 -0800, Marcus Reid wrote: > >On Sun, Dec 15, 2002 at 09:22:06AM -0500, Mike Tancsa wrote: > >> /sbin/dump -0uanf - /usr |gzip -9 | ssh > >> remoteuser@backupserver.example.com dd > >> of=/home/targetdir/root-server-al0.gz > > > >Agreed that dump is the way to go much of the time.. There is something > >that bothers me in your example though. Your backup machine trusts the > >server, > >and not the other way around. IMHO, the backup machine needs to be one of > >the most trusted machines on your network, like your management > >workstation. > > I agree. However, the target user on the backup server is non wheel and > the session is chrooted into its own directory. If servera is compromised, > the attacker can get at the account servera on the backupserver, and thats > it. > > >It logs into machines below it, and not the other way around. Compromise of > >server X should not allow access to the backups of every machine on the > >network! > > Not necessarily. If there is a password compromise on the one server, it > does not mean that there is access to all the other accounts on the backup > server. Also, if it were done the other way around, only the backup server > need to be compromised to gain access to all the other servers. > > How have you designed your backup system that avoids these issues ? Creating a chrooted environment capable of supporting SSH for each machine to be backed up seems impractical at best. Even if it were as simple as putting ssh and dd binaries into every chroot, I don't see the advantage that it has over having the backup machine make the outgoing connections. If the backup server is compromised in either configuration all of the backup data is exposed. But it's less likely to be possible if you can't connect to it. The last OpenSSH flaw I remember was an upstream vulnerability (rogue server exploiting vulnerable client) so obviously you're not invincible either way. But the difference in potential for vulnerability between an incoming SSH connection and being inside of a chroot with (suid root!) binaries and libs laying all over the place is pretty clear. Marcus To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021216044422.GA78227>