On 9/21/07, Scott Wells <[EMAIL PROTECTED]> wrote: > However, I don't fully agree with the sentiment that running a firewall > in a virtual machine (let's be specific, VMWare ESX) guest environment. > I'm running my firewall on a ESX 3.0.2 guest, and it works perfectly > fine. That being said, you have to be aware of the VM configuraton. > The majority of vulnerabilities in VMWare are patchable (so yes, someone > needs to do maintenance), but are also issues that affect the VMKernel > or service console, and with careful planning, the vulnerabilities can > largely be prevented for being used as exploits on external interfaces.
(I'd hoped you would have prefaced that with a statement like "these are my stock options talking, but...") This is the kind of bad advice that virtualization companies (and naive users of those technologies) need to stop spreading. This security model is flawed, and people should not rely on these virtual machine environments to provide firewall services. Here's an entirely realistic scenario at this point: - Administrator pays loads of money for VMware ESX; for better ROI, he intends to replace several systems on the network with one big system running a number of VMs. Maybe there is a full DMZ (say, 10 hosts) on this box. One virtual machine is configured as a firewall, intended to provide packet filtering and other network security services for the other DMZ VMs. - A vulnerability is discovered that allows an attacker who has presence in one VM to execute arbitrary code on the host OS, or transfer files between guest and host. (Both of these have happened already. In fact, VMware Tools seems to be the perfect bit of flawed gateway software to make this even easier.) Virtualized segmentation is compromised at this point. - Attacker now has presence on host OS and can fully control all 10 of the VMs running on the host. VM segmentation was supposed to prevent this, remember? This includes the firewall which he can now play fun games with such as overwriting the ruleset. He can sniff network traffic for all the VM hosts since he has direct access to the host interface. In one short subversion, 10 (11) systems have been compromised through one flawed security model. A weakness in one VM becomes the thing that makes compromising all the others dramatically easier. Why subject your firewall to that? At least in a traditional non-virtualized firewall model, the attacker would have to pull out real exploits and attack real (secured) services to compromise the firewall, and it wouldn't fall at the same time as the other hosts. Yes, these kinds of of flaws have (so far) been able to be patched, but a. They're becoming more frequent as more research goes into breaking out of VMs b. The impact of these flaws can be so high it doesn't justify risking the integrity of an entire network of machines at the same time when you get bit by it. Feel free to lump all of your IIS webservers onto a VM environment and let that get owned up and down. At least have the good sense to physically seperate your firewall (and other network security devices) out of that. DS
