Is It OK to Capture Packets in a Virtual Machine?
I’m a big fan of virtualization. I’ve been using virtual machines for decades; the isolation and resource sharing they give make it totally worth the extra effort needed to understand the technology and set them up. But there are a few circumstances where running something in a virtual machine may not be your best choice:
- Any program that will end up using essentially all of the processing power or memory of the host system. There are few advantages to placing a virtualization layer between the resource hog and the physical host.
- Running video/audio capture or playback programs is iffy because these depend on reacting quickly to encode or decode video streams. If there’s an extra delay, this can lead to choppy video or audio.
- Capturing packets from a network.
And that’s the focus of this article.
Packet capture is one of a small number of tasks performed on a computer that needs to be low-latency; the capture and analysis has to be completed very soon after the packet arrives or we start to fall behind in processing, leading to “capture loss” (where we never analyze some percentage of the traffic). See the references below for a blog on this.
We are commonly asked if it’s possible to run Zeek (the packet capture tool that’s part of AC-Hunter) inside a virtual machine. Running packet capture inside a virtual machine is tricky for the following reasons:
- Virtual machines are not necessarily running all the time; they may be paused for multiple microseconds to allow another VM to use the processor(s). While the VM is paused, we depend on the virtualization software to buffer incoming packets for that VM, and it may not be easy to measure how well the virtualization software buffers them.
- The more CPUs you allocate to a VM, the more difficult it is to schedule that VM to run.
- Running in a virtual environment means additional latency to packet capture, and higher chance of packet loss. The severity of both of these depends on the virtualization platform.
- Packet capture on a physical machine is relatively straightforward; one points the capture program at the interface connected to the mirror port/copy port/span port/tap. On a virtual machine, it may be tricky to connect a physical interface on the host to a virtual interface, especially as one wants to operate in promiscuous mode (listening to all packets coming from the span port) at both the host and virtual machine. The steps to do this depend on the particular virtualization platform you pick.
- When you first install Zeek in a VM, things may work fine; you may have enough CPU and memory that the capture process has very low packet loss. As you later add more virtual machines to the system, the Zeek system’s share of the CPU time will go down, potentially leading to higher packet loss that may not be apparent unless you actively and regularly monitor packet loss.
In short, we discourage it for the above reasons.
References:
https://www.activecountermeasures.com/packet-loss-or-why-is-my-sniffer-dropping-packets/
https://www.activecountermeasures.com/on-which-interface-should-i-capture-packets/
Bill has authored numerous articles and tools for client use. He also serves as a content author and faculty member at the SANS Institute, teaching the Linux System Administration, Perimeter Protection, Securing Linux and Unix, and Intrusion Detection tracks. Bill’s background is in network and operating system security; he was the chief architect of one commercial and two open source firewalls and is an active contributor to multiple projects in the Linux development effort. Bill’s articles and tools can be found in online journals and at http://github.com/activecm/ and http://www.stearns.org.