is a tap interface on linux vulnerable to snooping attacks

Question

If you have multiple VM's on a Linux host machine, and use a single tap interface on that host machine, is that network vulnerable to spoofing/mac spoofing attacks like a normal Ethernet network would be, or is there some intelligence in the way this is programmed that would prevent these kinds of attacks?

If you put the network interface of the guest VM in promiscuous mode, will it see the traffic to the other guest VM's?

I'm assuming it mimics a real Ethernet network, and is thus susceptible to these kinds of attacks, and VM's that don't trust each other should thus not be sharing the same tap device, but I can't find this confirmed or rejected.

Answer 1

I believe every Qemu instance, e.g. every VM will need its own tap interface. I doubt it is possible to run multiple VMs and use a single tap for that.

Anyway, putting an interface inside a VM into a promiscuous mode does not affect in any way the state of the corresponding tap in the host. VM doesn't even know whether the tap exists in the host or user-mode networking is used (so there is no corresponding interface in the host), or the host is Windows (Hyper-V) which has its own means of connecting VMs to the network. The vNIC in the VM is not the same thing as "tap" present on the host. They exist in different computers to begin with, like "in different realms", one of which is virtual.

Likewise, tap doesn't care if there is a VM behind it or it is something else, like a VPN (you can use the tap interface in OpenVPN, tinc or openconnect).

The tap API in the Linux is just the way to present an Ethernet NIC into the system and attach a software which receives packets leaving into that NIC and where the packets will appear that software injects back. That software might be Qemu, and on the other side it imitates the network and the HW interface of the NIC for the VM, in which case the VM sees some interface and gets packets the host output to the NIC. The Qemu works as the translator ("wire") between the software-side of the tap in the host and the emulated hardware-side of the virtual NIC in the VM. Promiscuous mode of the VM NIC is the "emulated hardware-side" business from the Qemu point of view and "stays inside the VM", which has nothing to do with the "software-side of the tap" business.

Notice also that you typically use those tap interfaces enslaved into a bridge on the host, and that bridge behaves like an Ethernet switch. It learns MAC addresses and sends packets only to the port where the corresponding MAC was learned, only resorting to the broadcasting when the MAC is unknown. Usually generic attacks like poisoning could affect the bridge behavior. For example, if one VM clones the MAC of other VM, it could direct that VM's traffic to itself, but that original VM wouldn't receive it, completely losing any network connection. You can set up static MAC entries into the bridge's table, instead of dynamic learning, and this problem will be alleviated, just like in a typical managed switch. And so on.