Reflex IPS adds security to your VM life

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.

It's also possible to set custom policies, and the one we found most interesting was an alert-and-deny policy for packet flooding that fits the profile of a denial-of-service (DoS) attack. SYN, Fragment, UDP, TCP and Internet Control Messaging Protocol flooding can be detected and automatically denied and/or otherwise spawn a high concern alert. Alas, distributed DoS attacks (we tried could not be filtered (we used more than 10,000 unique IP addresses in our attack).

Each host can then be tuned for a detection-sensitivity level (corresponding to the number of packets flooded) before the filter turns on for each packet type. You can select a single host or a 24 IP address range of VM hosts to be protected in this way. We tried to turn sensitivity to its highest level for our distributed DoS attack but RCC failed to keep up with the floods, in this, our most dastardly of attacks. RCC simply started to halt traffic, slowing packets flowing through the RCC link between the virtual network card in the VMware host, and its targeted/attacked server, until the attack was over.