>>>>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.
This archive was generated by hypermail 2b30 : Fri Sep 06 2002 - 13:08:22 PDT