PacketMotion Inc.’s new PacketSentry Virtual Probe now offers users more granular visibility into communication...
between virtual machines (VMs). The company says that the approach is a lighter-weight alternative to virtual firewalls such as VMware Inc.’s vShield App. But its design may run afoul of some VMware best practices.
According to Paul Smith, PacketMotion’s CEO, Virtual Probe is delivered as a virtual appliance that attaches to a virtual switch in “promiscuous mode.” As a result, Virtual Probe monitor can see traffic without providing that visibility to other VMs on the same host. From there, Virtual Probe can detect application-level transactions as they happen and stop them according to policy.
In theory, Virtual Probe could complement a virtual firewall but is “largely competitive,” said Jonathan Gohstand, PacketMotion's vice president of product management. Like virtual firewalls, Gohstand said, it also has a rules engine that can re-set IP connections if unauthorized transactions are detected. The company further asserts it detects more transaction types than VMware’s vShield virtual security products.
For example, says Smith, VMware’s vShield App (PDF file) can perform policy enforcement on security groups, vCenter groupings and the TCP 5 tuple (source IP, destination IP, source port, destination port, protocol), while PacketSentry can decode up to 55 types of data streams, including file or database-level information. “We’re getting transaction-specific data at a very granular level on many different protocols [like] specific files, folders, databases, and database tables, and seeing exactly what data entity is being addressed.”
Andrew Gahm, a systems and security engineer at South Jersey Healthcare, uses PacketMotion’s PacketSentry products for physical servers, which he said detected not only a virus that had attempted to write itself to servers on the network but also the end-user PC from which the virus originated and the user logged in at the time.
“I went immediately and shut down the machine and stopped it before it got anywhere else,” Gahm said. Similarly, “sometimes data shows up on a printer that shouldn’t be, and we want to know who put it there,” he said. “We try and track it down, and [PacketSentry] is giving us the tools we need to do that.”
The availability of PacketSentry Virtual Probe, which Gahm is beta-testing, will extend these capabilities to virtual networks, Gahm said. “I have some networks that are totally virtual … and I have no way of capturing that data without the Virtual Probe.”
Promiscuous mode a no-no?
Though broadly speaking, both PacketSentry Virtual Probe and VMware’s vShield products can be used to stop anomalous communications between VMs, the two work very differently, according to industry experts.
“This is much different than vShield App, which uses VMsafe-Net,” wrote Edward Haletky, CEO and analyst with The Virtualization Practice, in an email. “[The way] PacketSentry ties to a vSwitch [is] not at all like [vShield] App” and requires the virtual switch to be placed in promiscuous mode.
According to Neil MacDonald, Gartner Inc. vice president fellow, vShield App and products like it have network segmentation and firewalling capabilities, which is not how PacketMotion approaches network security.
“Could their technology be used to create separation of different workloads? Yes. But it’s not a firewall,” MacDonald said.
Meanwhile, VMware has, in the past, advised that virtual switches placed in promiscuous mode be strictly separated from those that are not. A more current VMware Knowledge Base article notes, “Promiscuous mode is disabled by default, and must not be turned on unless specifically needed, as network performance to the attached virtual machines may be affected.”
PacketMotion defends its use of promiscuous mode. “The bottom line is that we are not putting the entire vSwitch in promiscuous mode, just the port group that our system sits on. … Our [appliance] is the one VM that can see the traffic,” said Gohstand.
When it comes to network security monitoring, users have three choices, Gohstand said. Each has its drawbacks: using software agents within application servers, plugging into the hypervisor (as virtual firewalls do through the VMsafe application programming interfaces), or attaching to the virtual switch. Plugging into the virtual switch allows for agentless transaction monitoring that makes the product less obtrusive and easier to install and manage, Gohstand says, adding that application agents and inline firewalls can lead to “arguing with your database guy, or your VMware guy, about cobbling [a monitoring agent or virtual firewall] onto their application or their hypervisor.”
Furthermore, putting switches in promiscuous mode is commonplace in physical environments. “If we were to extend the VMware recommendation back to the physical world, it would invalidate the tens of thousands of installations of security gear that use promiscuous mode ports on traditional switches,” Gohstand said.
Gahm said that for his purposes, he has no issue with the virtual switch configuration. “We have other physical devices which do a similar thing with SPAN ports,” he said. “It’s not causing any problems.”
Beth Pariseau is a senior news writer for SearchServerVirtualization.com. Write to her at firstname.lastname@example.org.