Re: FW: use of base image / delta image for automated recovery from attacks

From: Scott MacKenzie (scottm@crystal.ncc.cc.nm.us)
Date: 09/05/02 

Date: Thu, 05 Sep 2002 11:26:13 -0600
From: Scott MacKenzie <scottm@crystal.ncc.cc.nm.us>
To: Ben Mord <bmord@icon-nicholson.com>

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 -'   `-----'

Relevant Pages

  • FW: use of base image / delta image for automated recovery from attacks
    ... Subject: Re: use of base image / delta image for automated recovery from ... The problem is that if you commit too eagerly, ... But in your typical web application, most partitions do not accrue important ... doing this in hardware, much like hardware raid. ...
    (SecProg)
  • RE: Help me select hardware....Some real world data that might help
    ... Help me select hardware and software options for very large server ... and a couple other lists. ... MBR+UFS2 for operating system partitions ... I looked at "Large data storage in FreeBSD", but that seems to be a stale ...
    (freebsd-current)
  • Re: 24 lost ticks with 2.6.20.10 kernel
    ... The main issue is that we read the hardware ... strange that you are losing that many ticks IMHO, ... This reverts commit 60cba200f11b6f90f35634c5cd608773ae3721b7. ...
    (Linux-Kernel)
  • Re: Questions about using EWF on CF
    ... > Since you use custom aplication have you though about solution that probably many of us use and that is to keep aplication specific ... > You can have two partitions one with OS and program and second with your custom data. ... You can perform commit and every system start up instead of shutdown. ...
    (microsoft.public.windowsxp.embedded)
  • Re: 24 lost ticks with 2.6.20.10 kernel
    ... The main issue is that we read the hardware ... strange that you are losing that many ticks IMHO, ... This reverts commit 60cba200f11b6f90f35634c5cd608773ae3721b7. ...
    (Linux-Kernel)