Hi Mike, Thanks for the info. I'd rather run monitoring such as tcpdump from the VM if possible and not the host as a simulation of a network appliance and with the intent eventually of giving others access to the VM and not the host. Here is the xml file for the private network: <!-- WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: virsh net-edit virbr1 or other application using the libvirt API. --> <network> <name>virbr1</name> <uuid>####</uuid> <forward mode='nat'/> <bridge name='virbr1' stp='on' delay='0' /> <mac address='52:54:00:##:##:##'/> <ip address='192.168.100.1' netmask='255.255.255.0'> </ip> </network> There are two VMs connected to this interface, and the monitoring or "appliance" VM is connected to both this and the external interface. Please let me know if I can provide more info that will be relevant. Thanks, Kevin On Tue, Mar 22, 2016 at 9:41 AM, Mike - st257 <silvertip257 at gmail.com> wrote:> On Mon, Mar 21, 2016 at 1:33 PM, Kevin Ross <sedecim at gmail.com> wrote: >> >> Hi folks, >> >> I posted this question to the KVM list, but I thought I'd try here >> too--sorry if this is the wrong place to post this, can you please >> direct me to the correct forum or list if so, thanks! >> >> I'm working on a network security project, using KVM installed on >> CentOS 6.7 through yum. I have a VM with the goal of using this as a >> network appliance, and two other VMs, one simulating an attack node >> and the other simulating a vulnerable webapp. These are all connected >> to the same internal private network set up in KVM. The idea with the >> network appliance VM is to have it act as if it's connected to a >> network tap so it can see the traffic between the other two VMs. I'm >> not able to see the traffic currently and would appreciate your help >> or suggestions to see if this is possible and how I can set this up if > > > From the KVM host you should be able to point tcpdump at the vnetX > interfaces and sniff. > I've had to do this on occasion (with a bridged network setup) when a web > hosting VM was being brute forced. > >> >> so. I came across some information online suggesting to have the >> interfaces in promiscuous mode, including the virtual NIC for the >> private network, and I've tried all combinations. Thanks for any help >> you can offer! > > > Start by determining what interface your VM is attached to. > > We have no idea the network layout of your KVM set up for VMs either. > Look at the XML for your VM to determine which interface it's tied to. > > -- > ---~~.~~--- > Mike > // SilverTip257 // > > _______________________________________________ > CentOS-virt mailing list > CentOS-virt at centos.org > https://lists.centos.org/mailman/listinfo/centos-virt >-- sedecim at gmail.com
On Tue, Mar 22, 2016 at 1:57 PM, Kevin Ross <sedecim at gmail.com> wrote:> Hi Mike, > > Thanks for the info. I'd rather run monitoring such as tcpdump from > the VM if possible and not the host as a simulation of a network >Then run tcpdump on the VM. Same command or commands you'd have ran on the host node.> appliance and with the intent eventually of giving others access to > the VM and not the host. Here is the xml file for the private network: > > <!-- > WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE > OVERWRITTEN AND LOST. Changes to this xml configuration should be made > using: > virsh net-edit virbr1 > or other application using the libvirt API. > --> > > <network> > <name>virbr1</name> > <uuid>####</uuid> > <forward mode='nat'/> > <bridge name='virbr1' stp='on' delay='0' /> > <mac address='52:54:00:##:##:##'/> > <ip address='192.168.100.1' netmask='255.255.255.0'> > </ip> > </network> > > There are two VMs connected to this interface, and the monitoring or > "appliance" VM is connected to both this and the external interface.I take it you've tried testing basic connectivity from the VMs to whatever default gateway is in place? I see Spanning Tree is enabled, so you might check that an interface isn't in the blocking state. brctl showstp <BRIDGE_INT> | egrep '^(em|eth|vnet)|state' I don't use the NAT network mode for KVM, so hopefully someone else can chime in on that piece. -- ---~~.~~--- Mike // SilverTip257 // -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20160324/38c7fb8c/attachment-0002.html>
Thanks, Mike. When running tcpdump on the VM I'm not seeing traffic unless it's explicitly intended for that particular VM, so no traffic between the other VMs is getting forwarded from the virtual interface to the "network appliance" VM. There is connectivity between the VMs on the private network and the "network appliance" VM which is acting as a gateway. Here's the output of the brctl command: virbr1 bridge id 8000.5254007e2f5b designated root 8000.5254007e2f5b root port 0 path cost 0 max age 19.99 bridge max age 19.99 hello time 1.99 bridge hello time 1.99 forward delay 0.00 bridge forward delay 0.00 ageing time 299.95 hello timer 0.29 tcn timer 0.00 topology change timer 0.00 gc timer 0.29 hash elasticity 4 hash max 512 mc last member count 2 mc init query count 2 mc router 1 mc snooping 1 mc last member timer 0.99 mc membership timer 259.96 mc querier timer 254.96 mc query interval 124.98 mc response interval 9.99 mc init query interval 31.24 flags virbr1-nic (0) port id 0000 state disabled designated root 8000.5254007e2f5b path cost 100 designated bridge 8000.5254007e2f5b message age timer 0.00 designated port 8001 forward delay timer 0.00 designated cost 0 hold timer 0.00 mc router 1 flags I'm not sure why virbr1-nic is showing up as disabled, and also why the vnet# interfaces don't show up (they do show up on another host, although VMs on that host are having the same non-promiscuous issue as these VMs). I've tried this with and without NAT, as well as with STP on/off with no effect. Thanks, Kevin