There is a software package that is used (or was up through w2k) 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:crispinat_private] > Sent: Wednesday, September 04, 2002 5:46 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 $200 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: 928-724-6639 ---<) | ; o |-' | | \--- Senior DBA/CARS Coordinator/Etc. --/ | _ | `--' `- Email: scottmat_private -' `-----'
This archive was generated by hypermail 2b30 : Thu Sep 05 2002 - 13:36:03 PDT