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:crispin@wirex.com]
>   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: scottm@crystal.ncc.cc.nm.us -'   `-----'