Perched | Security Education, Consulting, and Support
Security Solutions

Perched Blog

ROCK in a (Virtual)Box

rock_logo.png

Virtual machines are convenient. They’re especially nice for testing out new tools or creating small labs for a proof of concept or one-off application usage. Deploying tools like RockNSM in a virtual machine is not always intuitive, though. In this post, I want to share a couple of options and walk through a scenario deploying RockNSM 2.4 to monitor traffic on a physical host interface.

The specific approach of this post was inspired by Richard Bejtlich’s post on troubleshooting virtualization in Network Security Monitoring (NSM) applications. While I was not able to reproduce Richard’s exact experience, I do discuss several of the options that can impact NSM in a virtual machine. In a future blog, I’ll discuss how to build an entire NSM lab in a hypervisor. Stay tuned!

Use Cases

There’s a handful of approaches to using a network analysis platform in a VM. For the purposes of this post, we’re going to stick to desktop hypervisors (sometimes referred to as type-2 hypervisors). So here’s a couple of scenarios:

  • Use a virtual machine to monitor traffic on the hypervisor host — In this option, the VM is given a second interface that is bridged with the host or perhaps dedicated pass-through of a hardware network interface (this is called SR-IOV in modern systems, also called PCI passthrough)

  • Use a virtual machine to monitor traffic on an isolated virtual network — With this option, the VM never needs to be exposed to the outside network and has the advantage of being able to monitor isolated internal traffic between two VMs that may never leave the hypervisor

  • Use a virtual machine as a stand-alone tool to analyze network traffic by processing full packet capture files (PCAP) — This is the least resource intensive and only requires copying PCAP files to the sensor to run through the tools

We’re going to focus on the first scenario using a network bridge interface. The only difference between the first and the second are how you connect the VM to the network stack. In the last option, you really don’t even need a network interface at all if you wanted to perform analysis in a completely disconnected environment.

Hypervisors

So, there’s no shortage of hypervisors out there and probably any one of them will get the job done. The three that I’m most familiar with, at least relating to network sensors, are:

  • VMware Workstation or Fusion — This has been, was, or currently is the king for a long time. I don’t know its current ranking and don’t really care, but it tends to be pretty robust, flexible, and performant. It loads custom drivers into your host operating system of choice and generally uses existing operating system networking interfaces, making it easy to interact with guests. This hypervisor is NOT free, but their Player product is and offers a subset of features for tinkering.

  • Linux KVM hypervisor — This is built into the Linux kernel and the backend of many popular virtualization platforms. As a desktop hypervisor if you’re using Linux, I recommend Virtual Machine Manager as a front-end. This platform is obviously tied to Linux systems, but in my experience very performant, secure, flexible, and uses 100% native network, which gives you unlimited options to manipulate your virtual environment.

  • VirtualBox — I have mixed emotions about this platform. On the upside, it runs about everywhere with the same interface and mostly same options. It has a lot of great useful features, but more than anything, the price is right at $free. This is why it is the default backend for projects like Cuckoo sandbox and Vagrant. The cost to pay for “runs everywhere with fun features” is that it’s not always the most performant hypervisor. And I personally find the network stack very complicated. For example, NAT networking all happens in some magical place behind the scenes; more on this in a bit.

Because VirtualBox is so ubiquitous and free, I’m going to use it for this walkthrough. All the concepts here apply across the board though, and can also be translated to dedicated hypervisors like ESXi, RHEV, and HyperV.

Getting Started

Go ahead and install VirtualBox using your favorite means. If you’re on a Mac and you have Homebrew installed (you do have it installed, right? If not, get it now and it’ll be our little secret), I recommend doing the following

brew cask install virtualbox
brew cask install virtualbox-extension-pack # These are non-free extensions that help performance

If you’re on MacOS, you’ll also have to go to System Preferences -> Security & Privacy and enable the system extension to run.

If you’re on Windows, try out Chocolatey and you can do similar. If you’re on Linux, check out the instructions here to setup your package manager.

Next, head on over to https://rocknsm.io and download the latest ISO, which is 2.4.1 as of this writing.

Create the Virtual Machine

At this point, you’re ready to configure and deploy. The easiest way to do this is to leverage the new RockNSM manager script. See the screencast below for a walkthrough of what I did from here. Also you can head on over to the Rock Docs for more detailed information on your options.

If you found this blog useful, please subscribe to get the latest updates and check out the Perched and RockNSM on Twitter for more information that we hope you’ll find useful too. Thanks!