-----Original Message----- From: Crispin Cowan [mailto:crispinat_private] Sent: Wednesday, September 04, 2002 7:30 PM To: Ben Mord Cc: Webappsec Securityfocus.Com; SECPROG Securityfocus Subject: Re: use of base image / delta image for automated recovery from attacks 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 >> >> Ben Mord wrote: >> >> 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. 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. >> Obviously, you can't do this with partitions that accrue important >> state, e.g. a partition that stores database table data. >... 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. Right. This is why you would consolidate all state of any long-term significance on just a couple partitions, and why you would not put static application code on these changeable partitions. Fortunately, most large client/server application physical architectures do this anyhow, because these are two fundamentally different kinds of state with two very different sets of administrative, security, RAID, and backup requirements. People also tend to do this anyhow because layered logical architectures are popular with the GUI at one end, business logic in the middle, and persistence services at the other. This logical architecture maps naturally to a physical architecture that has a static web server, a static application server, and a database server that has static and changeable partitions. (I use the word static versus changeable instead of writeable versus unwritable because the "unchangeable" partitions might be written to for temporary swap space. Who knows what Windows does internally?) My point is that there should be a market out there for a hardware RAID device that can split designated partitions into a permanent base image partition and a temporary delta image partition, that has some simple but solid security measures to prevent the unauthorized remote modification of base images, and that can be configured to clear the delta image when the server is rebooted. If some vendor wished to implement this, they could then market this as a mechanism to help frustrate broad classes of attack that rely on the permanent modification of system or application files via buffer overflows, platform and middleware bugs, etc. The prevention of unauthorized modification of application data, of course, would not be addressed by this particular product. But there are many other techniques out there to defend application data. But those techniques all assume that your system itself has not been compromised at a lower level, which is where this product could help. I would have to think that these features would be relatively easy for a hardware RAID vendor to implement. (I'm just guessing, of course, with no knowledge of how hardware RAID works internally.) If anyone knows of such a product, I'd love to hear about it. Ben
This archive was generated by hypermail 2b30 : Thu Sep 05 2002 - 10:01:33 PDT