RE: use of base image / delta image for automated recovery from attacks
From: David Wheeler (dwheeler@ida.org)Date: 09/06/02
- Previous message: Bryan Ponnwitz: "Data Encryption"
- Maybe in reply to: Ben Mord: "use of base image / delta image for automated recovery from attacks"
- Next in thread: redhat: "Re: use of base image / delta image for automated recovery from attacks"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 06 Sep 2002 09:51:02 -0400 From: David Wheeler <dwheeler@ida.org> To: secprog@securityfocus.com
>>>>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.
>>>>
>>
>>>Ah. In that case, you can use something considerably less powerful than
>>>VMWare. All you need is a machine configured to boot from CD-ROM and use
>>>a RAM disk for scratch space. Numerous Linux distros are available that
>>>let you boot a stateless but functional system from CD-ROM.
>>>
>>
>>But RAM is expensive, and the directory structures of many systems (e.g.
>>Windows) are not sufficiently organized and standardized to make this
>>combination of bootable CDs and RAM drives practical.
So change the system.
If you really are worried about attackers taking down
your system, you need to choose the set of components necessary to
counter them. If you truly can't, then see if you can at least
partially apply the techniques available, but sometimes the
"unchangeable" is actually quite changeable if the reason is valid.
>>Even if you are
>>fortunate enough to be using Linux (or another FHS-compliant *nix), you
>>still can't fit a lot on a CD. Its not unusual today to have gigabytes of
>>static multimedia content on the web server. This particular problem can be
>>alleviated somewhat by using DVDs, but this is a temporary solution at best
>>which will become outdated quickly as our data requirements grow and hard
>>drives become cheaper.
Consider using a cheap hardware solution. For example, I'd look into
read-only IDE drive bays. They're often sold as a forensics tool,
but they'd work fine for this purpose too.
Just plug the bay into the IDE ribbon, and plug the IDE drive
into the bay. Now you have LOTS of read-only space.
Not enough space? Buy several.
With this approach, you can
buy bigger hard drives later, and you can buy commodity parts
all the way around. It's also easier to trust than a pure
software product, because it has very few parts.
This isn't really a "new" approach; most removable media
have a write-protect tab (and have had them for decades);
these bays simply create the
IDE disk equivalent of a write-protect tab.
The disadvantage of this approach
is that to make a change, you'll need to remove the disk
(though I think sometimes these bays are hot-swappable) and bring
the disk to a different machine for updating.
And a "temporary" solution of one DVD could still support LOTS of
data, and you could buy several if it's not enough.
IDE or SCSI would be faster than DVD, though.
>>>... but if you *do* want some state to persist, then you need a
>>>mountable writable partition. To protect it, you need some kind of
>>>access control management to decide who can do what to the writable
>>>partition, blah blah blah ... and before you know it, the security
>>>problem starts to look just like it does for conventional servers.
>>>
If you can separate what _has_ to be writeable to something small,
then you can use quick & easy backup approaches.
The rest can be read-only, protected by hardware.
That way, at least _most_ of the stuff is protected, and you can
recover far more quickly.
- Previous message: Bryan Ponnwitz: "Data Encryption"
- Maybe in reply to: Ben Mord: "use of base image / delta image for automated recovery from attacks"
- Next in thread: redhat: "Re: use of base image / delta image for automated recovery from attacks"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
