there is a software package that is used or was up through wNUMBERk on microsloth for this purpose ghost or some such one essentially takes a picture of the machine s proper config and then upon schedule or demand replaces the machine s current config with the proper picture it essentially over writes the entire disk drive especially good for student access machines at libraries etc ben mord wrote original message from crispin cowan mailto crispin wirex com sent wednesday september NUMBER NUMBER NUMBER NUMBER pm to ben mord cc webappsec securityfocus com secprog securityfocus subject re use of base image delta image for automated recovery from attacks i did my dissertation work in this area optimistic computing and so was interested in applying it to the security problem unfortunately you hit a bunch of problems a when can you commit a state as being good you can t run from a redo log forever the performance and storage penalties accumulate even log structured file systems garbage collect eventually so you have to commit sometime the problem is that if you commit too eagerly you might commit corrupted state if you commit too conservatively you eat performance and storage penalties b what do you do if you discover that there is corrupted state in the middle of your redo log and you want some of the critical state that comes after it you need some way to dig the corruption out of the middle and save the rest my dissertation solves this problem but you have to re write everything in my programming language c just doing this at all imposes substantial performance penalties i love vmware and use it every day the best NUMBER i ever spent on software but it is not very fast my proposed solution to the first two problems you mention is to be less ambitious the idea is that you never commit instead you simply revert to base state on reboot obviously you can t do this with partitions that accrue important state e g a partition that stores database table data but in your typical web application most partitions do not accrue important state for example your typical web server or application server could have their entire state reset back to a known base state during each reboot without harm the advantage of being less ambitious is that we have a quick and easy way to frustrate certain attacks without rewriting all of our software or spending lots of money on additional application specific coding the first two problems you describe only occur if we become more ambitious and try to apply these same techniques to for example the database table partitions where state changes remain important across reboots that would certainly be a nice touch but as you point out many problems would have to be addressed first and the hardest of these can not be abstracted away from the particular application not the least of these is the problem of writing heuristics for delineating good from malevolent state that task is roughly analogous to what antiviral software authors do for a living only this work could not be shared across many different systems as it would be specific to a paritcular application the third problem you mention performance penalty is an argument for doing this in hardware much like hardware raid another argument for doing this in hardware is hack resistance changing the base instance should require physical access to the console e g by requiring that you first flip a physical switch on your raid hardware or modify a bios setting if the base image can be modified remotely or by software then you have to worry about whether an implementation flaw might permit a cracker to modify the base image remotely ben ______ scott mackenzie dine college isd c phone voice mail NUMBER NUMBER NUMBER o senior dba cars coordinator etc _ email scottm URL 