I think you are not possible to do this on share network, where next hop of the network is directly your physical router. Nobody know the IP is Spoof if your VM change the IP Itself instead of following the DHCP.
If you really want to achieve this, you may self write a script to read ARP records from your Router and compare it to VM MAC Address , if it is not matched, then will be Spoof. You can avoid this by using. Advance , NAT Network Group where the Public IP is not control by the VM. On Tue, Jun 6, 2023 at 7:13 PM Will Conrad <wcon...@hivelocity.net.invalid> wrote: > How might one go about achieving this functionality without using security > groups? Is there another way *through cloudstack* to limit the users' > ability to change their instance IP address or otherwise use an arbitrary > IP address? > > For instance, if using a shared network for internet access with a publicly > routable class C assigned, a new instance/vm assigned to that network will > consume one of those IPs. What's to stop the user from manually changing > their IP or manually adding another IP from that subnet, which is > effectively "stealing" a second IP (aside from the obvious, that when > cloudstack tries to assign that "stolen" IP to another instance there will > be IP collisions on the network)? > > We really need to understand how this functionality works and what we can > do to prevent bad actors from being bad actors. > > Regards, > > Willard Conrad > DevOps Engineer > Hivelocity, LLC > > On Mon, May 22, 2023 at 10:02 AM Will Conrad <wcon...@hivelocity.net> > wrote: > > > Hi Wei, > > > > Thanks for your response. Advanced zone is being used with a guest > network > > type "shared". Disclaimer, I neither setup nor configured this > > cloustack zone or instance. How can I tell if security groups were > enabled > > when the zone was created? At this point, I am leaning towards they > > weren't, but need to confirm. > > > > Regards, > > > > Willard > > > > On Mon, May 22, 2023 at 8:40 AM Wei ZHOU <ustcweiz...@gmail.com> wrote: > > > >> Hi Will, > >> > >> What type of zone and network do you use ? > >> > >> As said before, the functionality works in the Advanced zones with > >> security > >> groups (as well as the Basic zones). > >> If you use the advanced zone and isolated networks (it seems so), there > is > >> no such functionality, as far as I know. > >> > >> -Wei > >> > >> > >> On Mon, 22 May 2023 at 14:00, Will Conrad <wcon...@hivelocity.net > >> .invalid> > >> wrote: > >> > >> > Thank you everyone, for your responses. > >> > > >> > I feel the need to further clarify my question: > >> > The spoofing and IP theft this thread is concerned with is related to > >> bad > >> > actors on cloudstack instances attempting to send out traffic as a > >> > different IP or attempting to utilize network IPs that aren't/weren't > >> > assigned to said VM by cloudstack. > >> > > >> > Based on some of the responses and a jira ticket from an old > cloudstack > >> > version: https://issues.apache.org/jira/browse/CLOUDSTACK-8559 > >> > I thought I would confirm that the spoofing and IP theft I am > >> immediately > >> > concerned with would not be an issue. However, I find that I am able > to > >> > manually modify an instance IP (from within the instance) and maintain > >> > connectivity using the modified IP after removing the original > >> > cloudstack-assigned IP. > >> > > >> > Method of modification was using iproute2 tools from within the VM: ip > >> addr > >> > add ..., ip addr del ..., ip route add ... > >> > > >> > Example: created new instance, received cloudstack assigned public IP, > >> > confirmed working. Logged into instance, manually added "stolen" IP, > >> > manually removed cloudstack assigned IP, re-added default gateway, > >> tested > >> > connectivity. Instance was able to communicate on the internet by both > >> > sending and receiving outbound pings, performing DNS resolution, and > >> > accepting inbound ssh connects via the new manually added IP. > >> > > >> > This is contradictory to what I expected. Does something have to be > >> done to > >> > enable this anti-spoofing functionality? Are there details I am > missing? > >> > > >> > Regards, > >> > > >> > Willard Conrad > >> > DevOps Engineer > >> > Hivelocity, LLC > >> > > >> > > >> > > >> > On Thu, May 18, 2023 at 11:07 AM Wei ZHOU <ustcweiz...@gmail.com> > >> wrote: > >> > > >> > > Yes, as Jithin said cloudstack uses iptables/ebtables/ipset to > >> prevent IP > >> > > spoofing in advanced zone with security groups. > >> > > > >> > > If the IP or mac address of vm instance is modified inside the vm by > >> the > >> > > user, the vm will not work. > >> > > > >> > > -Wei > >> > > > >> > > > >> > > On Thursday, 18 May 2023, Jithin Raju <jithin.r...@shapeblue.com> > >> wrote: > >> > > > >> > > > Hi Willard, > >> > > > > >> > > > I believe there is something implemented using iptables,ebtables > to > >> > > > prevent IP spoofing for security group enabled zones. You need to > >> take > >> > > this > >> > > > into account if you are using security group enabled zones. > >> > > > > >> > > > -Jithin > >> > > > > >> > > > From: Will Conrad <wcon...@hivelocity.net.INVALID> > >> > > > Date: Thursday, 18 May 2023 at 1:08 PM > >> > > > To: users@cloudstack.apache.org <users@cloudstack.apache.org> > >> > > > Subject: IP Spoofing and IP Theft > >> > > > Hello Community! > >> > > > > >> > > > It looks like cloudstack has built-iin protection to prevent IP > >> > > spoofing, I > >> > > > am wondering what kind (if any) of protections cloudstack has > >> built-in > >> > to > >> > > > protect the environment from IP theft, or is this a consideration > >> that > >> > > > should be taken into account when designing the network layout and > >> > > > offerings for tenants? > >> > > > > >> > > > Regards, > >> > > > > >> > > > Willard Conrad > >> > > > DevOps Engineer > >> > > > Hivelocity, LLC > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > >> > > > -- Regards, Hean Seng
