Reflex Technologies' Command Center is itself a virtual machine that sits on VMware's ESX server and acts as an intrusion-prevention system, watching connectivity activity between other VMs and the virtual network interface provided by VMware.

RCC watches either a reflection of or directly filtered network traffic flow between physical and virtual network interfaces and monitors and filters traffic based on a rules set of known hacks, cracks and odd behaviors between hosts.

RCC is a nervous beast that only occasionally mischaracterized traffic. Amusingly, it misidentified traffic coming from Virtugo's VirtualSuite (a competing VM management product) as indicative of an instance of eDonkey. Otherwise it was highly accurate.

This product is stunningly simple to use. Installation takes literally seconds. Two modes are available: an inline mode that rests between VM host instances and the virtual network cards in a VMware host server, and a bridged mode that listens to traffic mirrored from the interface. The inline mode can filter traffic based on default or administrator-modified packet filtration rules, while the bridged mode is a listen-only setup.

We used both modes, first as a filtered connection, then as a combined filtered and bridged connection so that we could monitor one host while filtering/monitoring the other one. Each VMware hardware host server had four to six VMs running on it. We used Microsoft's Internet Information Server 6 and Apache as sample applications on each server instance.

Once the RCC VM instance is alive, it immediately starts evaluating packets (or filtering if that's what you've chosen to do) and relationships between VM instances and the rest of the connected world. Sensors on multiple VMware hosts can be setup and linked to a single RCC console.

RCC then categorizes intrusion profile information it's evaluated into low-, medium- and high-concern categories (shown in a 3D bar graph as yellow, orange and red) when it sees a problem not in line with its rule set.

As an example, we probed Server Message Block ports on each server, an action that correctly triggered signature messages of several attack types. Additionally, we had one server pound the DNS ports of another hosted server to trigger the identification of a User Datagram Protocol (UDP) flood attack.