Sorry, I really hoped that this thread would die but ... This is an excellent solution to the "restore" problem, as is Jumpstart scripts and packages for Slowaris and (perhaps - I haven't tried using it) portupgrade and some scripts for *BSD). Separating the "system" and the "data" definitely contributes to making a faster recover. However the data remains tainted, so the issue of trusting the backup does not go away.
Suppose you use ssh. Suppose you plow your box and reinstall as described. Do your host keys get replaced. If you formatted the disk they do, but if you restore them from your data backups are they trusted? Yes, yes, I know no one would restore host keys from backups, but it make s the point. Data can be tainted. My earlier point stands also - if you have custom scripts or even non-executable files, and you restore from your old cron- tab entries, there might be some non-executable that gets changed to executable and bammo! you're screwed. So saying that backing up the data separately from the system is not a panacea because that data may be compromised. In fact it's probably *more* dangerous because after hours of restoring a production system under pressure there is a serious temptation to grab that saved data and throw it back up on the new 'clean' server to get things running as fast as possible. While I agree that separating the system and the data for restore purposes is a good solid plan, I do not agree that such a plan obviates the need to do forensics on the untrusted data to ensure that you do not repeat the hack on the restored machine. G On or about 2003.12.23 15:27:00 +0000, [EMAIL PROTECTED] ([EMAIL PROTECTED]) said: > An even better solution is to have a method of installing a machine where > the latest program packages can be installed and the configuration can be > repeated. Red Hat comes with this ability, by combining the "genhdlist" > program (comes with the anaconda-runtime package) with a script run via NFS. > Once you have that, you only need to backup the actual data, not the > configuration (so the issue of trusting the backup goes away). -- Gregory A. Gilliss, CISSP E-mail: [EMAIL PROTECTED] Computer Security WWW: http://www.gilliss.com/greg/ PGP Key fingerprint 2F 0B 70 AE 5F 8E 71 7A 2D 86 52 BA B7 83 D9 B4 14 0E 8C A3 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
