Monday, March 16, 2009

Network Security Appliance testing and QA with Virtualization

While working on our newest Intrusion Prevention appliance Sentinel IPS 4.0, we are always working to streamline and automate all testing. Unfortunately an inline bridged network device can be a challenge...

Here are some of the strategies that have worked in the past and some of the issues we are currently struggling with:

The old fashioned way (QA environment round 1):

What the team before I joined was using, 4 separate physical machines configured like this:

QA Attacker/Tester (loaded with stateful attack scripts) --> Router (192.168.x.x <-> 10.10.x.x) <--> Sentinel IPS (inline bridged appliance) <--> Switch <--> QA Target Host/s

This works but is in my mind too much equipment and software to maintain, not only that but power consumption is in microwave oven levels. Adding a new attacker or target platform requires loading or reloading another piece of hardware.

QA environment round 2:

Hello Vmware! I believe it was VMware Workstation for Windows 5.x or so which added a wonderful new network feature called "teaming" in which you could create virtual labs by daisy chaining VM's and virtual interfaces together allowing Vmware to handle all of the routing.

Here is how it worked (QA Team1):
Attacker VM (Gentoo) <-bridged interface0-> Sentinel IPS VM <-Nat interface1-> Target VM1 (Windows Server 2000) Target VM2 (CentOS 5.x)

So you simply assign all of the VM's to a single team and the one interface each to your network appliance so it will bridge the traffic from your Attacker/Tester VM to the Internal target VM's. With one command you can start and stop the entire team or add and modify the attacker and target OS's. Adding Backtrack LiveCD as one of the attacker's is easy, simply install their VM and add it into the team using the bridged interface.

Now to avoid confusion there are two bridges in action, one which bridges the attacker and network appliance (Sentinel IPS in my case) to your normal physical LAN. This is chosen automatically by VMware but if you are on a laptop which may switch between wireless and wired networks you will want to manually create a bridged interface for your wireless card. They make it dead simple to switch your team interfaces around when your not on wireless.

The second bridge is the network appliance itself! If it is an inline bridge device like our IPS, then it will bridge the already bridged interface to the private NAT network which VMware created automatically. The auto NAT network is usually some derivative of 192.168.1xx.x which likely won't clobber your normal LAN.

Ok... so that seems like the perfect setup and it has worked rock solid for us requiring only one Windows machine with VMware, one actual real network interface and 2+ gig's of RAM. Pretty easy to come by these days.

Why do we want a new setup? Well I had to splurge on a Macbook Pro last year and VMware fusion does not support teaming.... Seem like small potatoes but it kills me that I can't put my 4 gigs or ram to good use. Yes my drive is encrypted :)

*** Update: maybe time to try Convirt 1.0 on my Mac

1 comment:

PAT Testing Books said...

This process of testing acquires special significance where you are running a business, school, hotel, or any other organization.