If the incoming traffic can be received by every guest KVM, it is a security issue. I can see others incoming traffic, so others can see my incoming traffic.
Is there a way to prevent this?
Is there a way to prevent this?
Running iftop on KVM, there are lots traffics to other IPs (other guest KVM) security issue?
- Thread starter Inlakesh
- Start date
No, this is no security issue. This is how bridged ethernet works. If you want to transfer secret data you have to use encryption.
Anyway, to just hide the traffic from other VMs you can use VLANs (or separated physical networks).
Within the VM you can activate the firewall for the network card, in the options you activate it and also the IP filter and MAC filter, set the default policy for input and output to drop. Under "IPSet" you create a new set "ipfilter-net0" (the name "net0" must match the interface under Hardware), there you add the IPs that the VM can use. Finally, under the firewall itself, you create two ACCEPT rules, one for in with destination "+ipfilter-net0" and the other for out with source on "+ipfilter-net0".
Thats the way we're doing it already. But if i take a look at iftop or running a tcpdump i still see traffic from other vm from the same host. Even if i create a DROP & DROP rule and just watch iftop connected with NoVNC, i'm able to see other guests traffic.
To prevent ip-spoofing it works well but in our setup not to prevent seeing other traffic. I am also able to see other traffic with a network adapter without any ip assigned.
ALL traffic? I highly doubt that. You should be seeing mostly broadcast and multicast traffic from other VM's (e.g. ARP who-has packets, mdns/bonjour, IPv6 router adverts, and the like). You will also see some small amount of traffic from VM's whose MAC has expired from the bridge's cache. That's just how switched Ethernet works. Only way to prevent it is with VLAN's.
The Linux bridge _is_ a switch. It works just like a physical switch with a MAC cache. It even supports Spanning Tree. The first packet from a new MAC or one that's expired from the cache will be flooded, as will broadcast and all or some multicast traffic (depending on IGMP snoop settings). But the large majority of traffic will not be flooded to all ports.
If the OP is indeed seeing all traffic from other VM's then something is wrong.
I've just tested this again and it only remains with ARP requests and a few STP packets, which I don't consider to be particularly dramatic. In shared environments such as server hosting or VMs, that's just the way it is, you can't set up a separate VLAN for every 2 EUR VPS customer, it doesn't make sense.
What I can't track is which other IP is communicating with which one, so I only see the traffic intended for my IP or the broadcast packets.
What I can't track is which other IP is communicating with which one, so I only see the traffic intended for my IP or the broadcast packets.
Thank you for correcting me. Switching does sound much more sensible (and efficient for the "bridge" and the VMs).Calling it a "Linux Bridge" is unfortunately confusing (or my terminology is wrong?). I checked the manual and it also mentions that the Linux bridge can be thought of as a virtual switch.
I'm not sure where the terminology comes from, why they call it a "bridge". Open Virtual Switch seems more clear I guess, although the real purpose of OVS is to do policy routing at layer 2 (things like QinQ encapsulation), which the standard bridge can't do.
The other traditional term is "hub". Those were devices that flooded all packets to all ports but they went away when gigabit Ethernet arrived since half-duplex gigabit was never really a thing (even though it is in the spec).
ETA: To be clear, a "hub" was a half-duplex device that just acted as a repeater. It more-or-less simulated the behavior of coax Ethernet.
Last edited: