Virtual firewall

So long as a computer network runs entirely over physical hardware and cabling, it is a physical network. As such it can be protected by physical firewalls and fire walls alike; the first and most important protection for a physical computer network always was and remains a physical, locked, flame-resistant door.[1][2] Since the inception of the Internet this was the case, and structural fire walls and network firewalls were for a long time both necessary and sufficient.

Since about 1998 there has been an explosive increase in the use of virtual machines (VM) in addition to — sometimes instead of — physical machines to offer many kinds of computer and communications services on local area networks and over the broader Internet. The advantages of virtual machines are well explored elsewhere.[3][4]

Virtual machines can operate in isolation (for example as a guest operating system on a personal computer) or under a unified virtualized environment overseen by a supervisory virtual machine monitor or "hypervisor" process. In the case where many virtual machines operate under the same virtualized environment they might be connected together via a virtual network consisting of virtualized network switches between machines and virtualized network interfaces within machines. The resulting virtual network could then implement traditional network protocols (for example TCP) or virtual network provisioning such as VLAN or VPN, though the latter while useful for their own reasons are in no way required.

There is a continued perception that virtual machines are inherently secure because they are seen as "sandboxed" within the host operating system.[5][6][7] It is often believed that the host, in like manner, is secured against exploitation from the virtual machine itself[8] and that the host is no threat to the virtual machine because it is a physical asset protected by traditional physical and network security.[6] Even when this is not explicitly assumed, early testing of virtual infrastructures often proceeds in isolated lab environments where security is not as a rule an immediate concern, or security may only come to the fore when the same solution is moving into production or onto a computer cloud, where suddenly virtual machines of different trust levels may wind up on the same virtual network running across any number of physical hosts.

Because they are true networks, virtual networks may end up suffering the same kinds of vulnerabilities long associated with a physical network, some of which being:

• Users on machines within the virtual network have access to all other machines on the same virtual network.
• Compromising or misappropriating one virtual machine on a virtual network is sufficient to provide a platform for additional attacks against other machines on the same network segment.
• If a virtual network is internetworked to the physical network or broader Internet then machines on the virtual network might have access to external resources (and external exploits) that could leave them open to exploitation.
• Network traffic that passes directly between machines without passing through security devices is unmonitored.

The problems created by the near invisibility of between-virtual machine (VM-to-VM) traffic on a virtual network are exactly like those found in physical networks, complicated by the fact that the packets may be moving entirely inside the hardware of a single physical host:

• Because the virtual network traffic may never leave the physical host hardware, security administrators cannot observe VM-to-VM traffic, cannot intercept it, and so cannot know what that traffic is for.
• Logging of VM-to-VM network activity within a single host and verification of virtual machine access for regulatory compliance purposes becomes difficult.
• Inappropriate uses of virtual network resources and bandwidth consumption VM-to-VM are difficult to discover or rectify.
• Unusual or inappropriate services running on or within the virtual network could go undetected.

There are security issues known only in virtualized environments that wreak havoc with physical security measures and practices, and some of these are touted as actual advantages of virtual machine technology over physical machines:[9]

• VMs can be deliberately (or unexpectedly) migrated between trusted and untrusted virtualized environments where migration is enabled.
• VMs and/or virtual storage volumes can be easily cloned and the clone made to run on any part of the virtualized environment, including a DMZ.
• Many companies use their purchasing or IT departments as the IT security lead agency, applying security measures at the time a physical machine is taken from the box and initialized. Since virtual machines can be created in a few minutes by any authorized user and set running without a paper trail, they can in these cases bypass established "first boot" IT security practices.
• VMs have no physical reality leaving not a trace of their creation nor (in larger virtualized installations) of their continued existence. They can be as easily destroyed as well, leaving nearly no digital signature and absolutely no physical evidence whatsoever.

In addition to the network traffic visibility issues and uncoordinated VM sprawl, a rogue VM using just the virtual network, switches and interfaces (all of which run in a process on the host physical hardware) can potentially break the network as could any physical machine on a physical network — and in the usual ways — though now by consuming host CPU cycles it can additionally bring down the entire virtualized environment and all the other VMs with it simply by overpowering the host physical resources the rest of the virtualized environment depend upon.

This was likely to become a problem, but it was perceived within the industry as a well understood problem and one potentially open to traditional measures and responses.[10][11][12][13]

Virtual firewalls can operate in different modes to provide security services, depending on the point of deployment. Typically these are either bridge-mode or hypervisor-mode (hypervisor-based, hypervisor-resident). Both may come shrink wrapped as a virtual security appliance and may install a virtual machine for management purposes.

A virtual firewall operating in bridge-mode acts like its physical-world firewall analog; it sits in a strategic part of the network infrastructure — usually at an inter-network virtual switch or bridge — and intercepts network traffic destined for other network segments and needing to travel over the bridge. By examining the source origin, the destination, the type of packet it is and even the payload the VF can decide if the packet is to be allowed passage, dropped, rejected, or forwarded or mirrored to some other device. Initial entrants into the virtual firewall field were largely bridge-mode, and many offers retain this feature.

By contrast, a virtual firewall operating in hypervisor-mode is not actually part of the virtual network at all, and as such has no physical-world device analog. A hypervisor-mode virtual firewall resides in the virtual machine monitor or hypervisor where it is well positioned to capture VM activity including packet injections. The entire monitored VM and all its virtual hardware, software, services, memory and storage can be examined, as can changes in these . Further, since a hypervisor-based virtual firewall is not part of the network proper and is not a virtual machine its functionality cannot be monitored in turn or altered by users and software limited to running under a VM or having access only to the virtualized network.

Bridge-mode virtual firewalls can be installed just as any other virtual machine in the virtualized infrastructure. Since it is then a virtual machine itself, the relationship of the VF to all the other VM may become complicated over time due to VMs disappearing and appearing in random ways, migrating between different physical hosts, or other uncoordinated changes allowed by the virtualized infrastructure.

Hypervisor-mode virtual firewalls require a modification to the physical host hypervisor kernel in order to install process hooks or modules allowing the virtual firewall system access to VM information and direct access to the virtual network switches and virtualized network interfaces moving packet traffic between VMs or between VMs and the network gateway. The hypervisor-resident virtual firewall can use the same hooks to then perform all the customary firewall functions like packet inspection, dropping, and forwarding but without actually touching the virtual network at any point. Hypervisor-mode virtual firewalls can be very much faster than the same technology running in bridge-mode because they are not doing packet inspection in a virtual machine, but rather from within the kernel at native hardware speeds.

• Virtual security appliance
• Network function virtualization

• "Zeus Bot Appears in EC2 Cloud, Detected, Dismissed" Babcock, Charles. InformationWeek Dec 2009
• "40,000 Firewalls! Help Please!?" Texiwill. The Virtualization Practice. Sept 2009
• "OPINION / Why do we need virtual security? " Ben-Efraim, Amir. Government Security News. Aug 2009
• "Keep Your Virtual Networks Safe" Zillion Magazine. July 2009
• "The virtual blind spot" Schultz, Beth. NetworkWorld. July 2010
• "Cloud security in the real world: 4 examples" Brandel, Mary. CSO: Security & Risk. June 2010
• "Securing mixed environments - not everybody will be virtualized" Ogren, Eric. ComputerWorld. June 2010
• "New security tools protect virtual machines" Strom, David. Network World March 2011