Passing port-mirroring to VM in KVM

[Dave]

Hi, all -

I know similar things have been covered before, but after extensive searching, I can't find a solution that's working for me.

On a new KVM server, I have an interface that is port-mirrored to various ports on our switch. When I tcpdump that interface, I can see that traffic. Let's call the interface eth1.

I have a bridge set up, br1, bound to that interface. When I tcpdump that interface, I can again see the port mirrored traffic.

However, when I start the Security Onion virtual machine in KVM, it creates a vnet1 interface. That vnet1 interface does *not* carry the port mirrored data, either when tcpdump'd from within the virtual machine or on the KVM server itself. All I can see are some STP requests.

The VM is configured as such:

<interface type='bridge'>
<source bridge='br1'/>
<model type='virtio'/>
</interface>

The bridge is configured as:

auto br1
iface br1 inet manual
bridge-ports eth1
bridge_stp off
bridge_maxwait 0
post-up ip link set br1 address XX:XX:XX:XX:XX:XX

The interface on the KVM server is configured as:

auto eth1
iface eth1 inet manual
pre-up ifconfig $IFACE up
post-down ifconfig $IFACE down

The same issues occur whether or not the interfaces are set as promiscuous.

Any advice? Thanks so much.

-Dave

[Doug Burks]

Hi Dave,

I don't have any experience with KVM, so I'll invite anyone with KVM
experience to chime in with better advice.

Is there somewhere in KVM that you've added the Security Onion vnet1
interface to the br1 bridge?

Have you seen the following?

https://help.ubuntu.com/community/KVM/Networking

https://wiki.ubuntu.com/KvmWithBridge

> --
> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at http://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.



--
Doug Burks

[Michal Purzynski]

On 3/8/14, 1:07 PM, Doug Burks wrote:
> Hi Dave,
>
> I don't have any experience with KVM, so I'll invite anyone with KVM
> experience to chime in with better advice.
>
> Is there somewhere in KVM that you've added the Security Onion vnet1
> interface to the br1 bridge?
>
> Have you seen the following?
>
> https://help.ubuntu.com/community/KVM/Networking
>
> https://wiki.ubuntu.com/KvmWithBridge
>
>

So it looks like the best idea is to use the pf_ring magic. I have no
experience with it, talk to Luca.

There are at least two ways to acomplish it. One, by using a two stage
pf_ring driver.

http://www.ntop.org/products/pf_ring/vpf_ring/

^^ vPF_RING - install one part in the host OS, another in the VM and
your packets should be delivered directly from the capture card to the
VM applications without any bottleneck.

I guess this comparision tells a story -
http://www.ntop.org/wp-content/uploads/2011/08/igb_capture_perc.png

A second option (I use it in a home SO installation) is to pass-through
a capture card to a VM. Personal experience note - not all cards work
well with it, you might have to test a few before you find something
that works. Intel usually does.

http://www.ntop.org/pf_ring/10-gbit-pf_ring-dna-on-virtual-machines-vmware-and-kvm/

Also make sure that you have enough physical cores and RAM. If other VMs
will be stealing the CPU cycles away from your sensor(s) and/or server
the performance could suffer. To make things worse, it will be hard for
us to help debugging it if you don't mention every time that your SO is
in the VM.

First of all, make sure your server will not steal cycles from your
sensor. It's OK for monitoring a DSL link like I do in home but that's it ;)

Also, think about the impact of the full packet capture on your storage
subsystem - SAN with iSCSI, NAS with NFS, etc. If you have a high
traffic levels and you write pcaps, you are stealing IOPS from other VMs
using the same shared storage. A local something just for pcaps might
help here.

We've got a golden rule here for what kind of workloads we don't
virtualize. Anything that does use a lot of the following resources CPU,
RAM, IO is a poor candidate for virtualization.

And guess what - a good NSM needs all of them :)

Your mileage may wary, depending on your workload, how many physical
cores under the hood, the amount of traffic, Bro and Snort
configuration, etc.