wido commented on issue #12210: URL: https://github.com/apache/cloudstack/issues/12210#issuecomment-3646370259
> > > Q: This does not segregate bad actors from each other on the same hypervisor, does it? Reason for Q: The assumption here is that the Client instances are semi under your control, to not use the root user to assign secondary IPs on the guest interfaces, correct? Also, you can't use anything like privacy extensions > > > > > > They can assign additional IPs if they want, but this will never reach the routing table of the hypervisor. These IPs will never function nor work. > > > I would, for the sake of security, also enforce a source guest-MAC source guest-IP and destination guest-MAC Destination guest-IP filter rules on the guest interfaces. inside the hypervisor > > > > > > The CloudStack Security Grouping already does that. Packets coming out of the VM are matched on the source IP address and MAC address. If it doesn't match what CloudStack expects it is dropped by the HV. Already existing functionality. > > > I come from a setup where I have users sharing L2 VLANs between guests, and then segregating their L2 VLANs with a firewall to the rest of the world. > > > > > > Yes, but as mentioned, CS already does this. > > agree. security group should be always enabled in the zone/network. Yes, don't disagree there. But this network model doesn't allow for spoofing MAC or hijacking IPs. Without security groups you could sent out IP packets with a spoofed source address, which can be used for DDoS amplification attacks. We should always filter in this network setup to prevent such traffic being sent from the VM. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
