Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

A Look at Blue Lane VirtualShield: Page 3 of 8

Protection You Didn't Know You Needed

We were impressed that Blue Lane develops inline patches for vulnerabilities that have been announced, but for which no vendor patch yet exists. By analyzing vulnerabilities discussed on venues like Bugtraq and Full-Disclosure mailing lists, the company determines the underlying problem and develops virtual patches for these zero-day exploits. Once the vendor releases an official patch, Blue Lane analyzes it as it would any patch, makes needed changes to the initial inline patch and distributes it.

A good example of this process is the recent Microsoft DNS RPC buffer overflow (CVE-2007-1748). Microsoft released an advisory on April 12, a CERT advisory was issued April 13 stating that exploits were available, and Blue Lane provided an inline patch on April 13. Microsoft finally released the official patch on May 8--leaving servers vulnerable for more than three weeks.

 

With VirtualShield, Blue Lane also has started offering policy-based filtering. This lets the product detect and rectify some problems with network traffic that aren't normally addressed by vendor patches. For instance, Blue Lane claims to protect servers only--it makes no effort to replicate vendor patches for client applications. But the company also realizes there are times when IT needs to run a Web browser on a server, maybe to download patches or register software, a practice that could expose the server to malicious network traffic. To counter this risk, Blue Lane offers a policy that limits Web browsing to only sites that have been whitelisted by the administrator. Other included policies can block connection attempts to a Microsoft SQL database with the user name "sa" and a blank password (some versions of SQL Server and the Microsoft Data Engine had a blank sa password as the default) or block duplicate DCERPC bind requests. Because these policies won't apply in all situations the way patches would, they're not activated automatically. IT must choose which to enable.

During our tests, to better understand its capabilities, we asked whether VirtualShield could block a range of scenarios. Many times the answer was yes, but our contact furiously scribbled notes to take back to the development team when we brought up situations its policies didn't cover, including suggestions to block PHP remote includes or Windows login attempts after a number of failed tries, to shut down brute-force password guessers. This is an area where Blue Lane says it plans to expand, and the company promises to include the ability for admins to write custom policies in the next major version.

Specialized Protection

VirtualShield comprises two parts, both of which run as VMs under VMware. By monitoring traffic at the hypervisor level, VirtualShield Gateway brings protection as close as possible to your virtual servers. In the simplest case, this is implemented in VMware ESX by creating two virtual switches, or vSwitches. The first accepts all incoming traffic from a physical NIC and passes it along in promiscuous mode to the VirtualShield VM. VirtualShield does its magic, then passes the traffic out through a second vSwitch, to which all other VMs are connected. Note that in this design, traffic between VMs does not pass through the VirtualShield Gateway. Other configurations are possible, including multiple VirtualShield Gateways or passing a VLAN trunk through the gateway, so that the gateway sees the different networks.