Running iftop on KVM, there are lots traffics to other IPs (other guest KVM) security issue?

Inlakesh

Well-Known Member
Jan 13, 2019
75
4
48
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?
 
If the incoming traffic can be received by every guest KVM, it is a security issue.

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.
 
I'll check this again for myself and see if that's the case. I primarily used this to prevent IP spoofing.

Can you perhaps give me an overview of your exact configuration? I would then check myself again.
 
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.
 
Maybe a Linux virtual bridge is the wrong technology for your use case? Maybe a bridge per VM and your own router VM would be better? I have no experience with OVS or the new SDN, but maybe they (can) work as switches instead of bridges?
 
Is there a way to prevent this?
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.
 
Maybe a Linux virtual bridge is the wrong technology for your use case? Maybe a bridge per VM and your own router VM would be better? I have no experience with OVS or the new SDN, but maybe they (can) work as switches instead of bridges?
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.
 
  • Like
Reactions: leesteken
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.
 
  • Like
Reactions: BobhWasatch
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.
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.
 
  • Like
Reactions: BobhWasatch
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:
  • Like
Reactions: leesteken

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!