Re: IP Spoofing and IP Theft
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 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 > 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 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 >> .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 > >> 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 > >> 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 > >> >
Re: guest.cpu.mode per guest/vm on the same KVM host
Hey, Ok. I created https://github.com/apache/cloudstack/issues/7600, hope this gonna be resolved soon. út 6. 6. 2023 v 16:20 odesílatel Rohit Yadav napsal: > Hi Lukáš, > > It's not possible to do it on per VM basis, however, do explore the extra > config feature if that allows for some customisation: > https://www.shapeblue.com/cloudstack-feature-first-look-enable-sending-of-arbitrary-configuration-data-to-vms/ > > Not ideal - a workaround may also be to do it on one-time basis by setting > guest.cpu.mode property in agent.properties for the VM you want to deploy > and once it's deployed, revert the cpu mode setting and restart the agent > on the KVM host. > > > Regards. > > > From: Daan Hoogland > Sent: Tuesday, June 6, 2023 19:45 > To: users@cloudstack.apache.org > Subject: Re: guest.cpu.mode per guest/vm on the same KVM host > > Lukáš > This is an agent property, which means per host at least. I don't know > of a way to make this per VM, but if you can do this on KVM, it seems > like a reasonable feature request. > > On Tue, Jun 6, 2023 at 3:56 PM Lukáš Mrtvý wrote: > > > > Hello, > > Is possible somehow to set guest.cpu.mode per guest ( VM ) ? I would like > > to create on the same KVM host VM with guest.cpu.mode=host-passthrough > and > > a second VM without any passthrough. Is it possible or this setting is > > global / per KVM host? Thanks > > -- > > BR, > > Lukáš Mrtvý > > > > -- > Daan > > > > -- S pozdravem Lukáš Mrtvý
Re: guest.cpu.mode per guest/vm on the same KVM host
Hi Lukáš, It's not possible to do it on per VM basis, however, do explore the extra config feature if that allows for some customisation: https://www.shapeblue.com/cloudstack-feature-first-look-enable-sending-of-arbitrary-configuration-data-to-vms/ Not ideal - a workaround may also be to do it on one-time basis by setting guest.cpu.mode property in agent.properties for the VM you want to deploy and once it's deployed, revert the cpu mode setting and restart the agent on the KVM host. Regards. From: Daan Hoogland Sent: Tuesday, June 6, 2023 19:45 To: users@cloudstack.apache.org Subject: Re: guest.cpu.mode per guest/vm on the same KVM host Lukáš This is an agent property, which means per host at least. I don't know of a way to make this per VM, but if you can do this on KVM, it seems like a reasonable feature request. On Tue, Jun 6, 2023 at 3:56 PM Lukáš Mrtvý wrote: > > Hello, > Is possible somehow to set guest.cpu.mode per guest ( VM ) ? I would like > to create on the same KVM host VM with guest.cpu.mode=host-passthrough and > a second VM without any passthrough. Is it possible or this setting is > global / per KVM host? Thanks > -- > BR, > Lukáš Mrtvý -- Daan
Re: guest.cpu.mode per guest/vm on the same KVM host
Lukáš This is an agent property, which means per host at least. I don't know of a way to make this per VM, but if you can do this on KVM, it seems like a reasonable feature request. On Tue, Jun 6, 2023 at 3:56 PM Lukáš Mrtvý wrote: > > Hello, > Is possible somehow to set guest.cpu.mode per guest ( VM ) ? I would like > to create on the same KVM host VM with guest.cpu.mode=host-passthrough and > a second VM without any passthrough. Is it possible or this setting is > global / per KVM host? Thanks > -- > BR, > Lukáš Mrtvý -- Daan
guest.cpu.mode per guest/vm on the same KVM host
Hello, Is possible somehow to set guest.cpu.mode per guest ( VM ) ? I would like to create on the same KVM host VM with guest.cpu.mode=host-passthrough and a second VM without any passthrough. Is it possible or this setting is global / per KVM host? Thanks -- BR, Lukáš Mrtvý
Re: [VOTE] Upgrade Log4j to Log4j2
João, Technically, for lazy consensus a vote thread needs three +1 (binding) votes which are only counted towards a decision or approval [1]. Since there are no objections but concerns shared so far, the PR can be reviewed, tested and merged as any other PR as long as it meets the community review and merge guidelines, in this case since the PR is a large one I would request additional manual QA and upgrade tests be done to ensure there is no stability/upgrade regression(s). [1] 3.2.1: https://cloudstack.apache.org/bylaws.html Regards. From: João Jandre Paraquetti Sent: Tuesday, June 6, 2023 01:36 To: users@cloudstack.apache.org ; d...@cloudstack.apache.org Subject: Re: [VOTE] Upgrade Log4j to Log4j2 Hi all, This voting has been going on for quite some time already. In the meantime, more tests have been done and the PR has been verified as working with both mbx and BO. As we did not get any -1 votes, and achieved the minimum of three +1s, I will therefore close this vote and propose we proceed in the PR. Any remaining issues people might have with the PR can be addressed in the PR's discussions in github, so that we can finally merge the PR. Best regards, João Jandre (JoaoJandre) On 18/05/2023 17:29, Sidimar Carniel wrote: > Important effort in this work! > > [ ] +1 approve > > Regards, > Sidimar Carniel > > > > Em qua., 17 de mai. de 2023 às 10:27, Rodrigo D. Lopez < > rodrigoduartelo...@gmail.com> escreveu: > >> Thanks for the great work! >> >> Based on discussions in PR and the discussion thread[1]. My vote is +1. >> >> Log4j v1 (deprecated) and its current alternative reload4j in use in ACS >> are not ideal for the long run. Therefore, for the future of ACS, and to >> enable us to keep evolving, the upgrade is most welcome. >> >> Regards, >> Rodrigo Lopez >> >> [1] https://lists.apache.org/thread/261j7m0p5mr4q7yclvo49mwhkxz4yov2 >> >> Em qua., 17 de mai. de 2023 às 09:41, Daan Hoogland < >> daan.hoogl...@gmail.com> >> escreveu: >> >>> -0 >>> >>> Joao, Daniel reacted negatively to my question to create a proxy with bad >>> arguments and I had no time to respond yet. I think not adding a proxy at >>> this time is a missed opportunity and I would full heartedly +1 if we >> had. >>> Not creating a proxy class (with or without configurability) is a waste >> of >>> your effort. >>> All the standardisation of calls is very useful irrespective. >>> >>> On Tue, May 16, 2023 at 8:45 PM Daniel Salvador >> >>> wrote: >>> Hello, João Considering the discussion we had in the thread[1] and that the >> conflicts will be mostly regarding loggers names (which is simple to fix), I am >> +1 >>> on the proposal. Best regards, Daniel Salvador (gutoveronezi) [1] https://lists.apache.org/thread/261j7m0p5mr4q7yclvo49mwhkxz4yov2 On Tue, May 16, 2023 at 1:28 PM João Jandre Paraquetti < j...@scclouds.com.br> wrote: > Hello guys, > > I am opening this voting thread as result of the discussion in thread > "ACS upgrade to Log4J2 version 2.19"[1]. > > The voting aims to continue the efforts and conclude the upgrade of >> the > ACS logging library to Log4j2 through PR 7131[2]; merge the PR as >> soon > as possible and provide ways to contributors solve the conflicts >>> easily, > so all the contributors have time to fix their merge conflicts before > 4.19; announce that change in the release notes and provide ways to > users upgrade their customization made to the default log4j > configuration files. > > For sanity in tallying the vote, can PMC members please be sure to indicate > "(binding)" with their vote? > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Best regards, > João Jandre (JoaoJandre) > > [1] https://lists.apache.org/thread/261j7m0p5mr4q7yclvo49mwhkxz4yov2 > [2] https://github.com/apache/cloudstack/pull/7131 > > >>> >>> -- >>> Daan >>>
Re: Difference in functionality of Advanced Networking With and Without Security Groups
Thank you for your quick response, Wei. It was helpful. Regards, Willard On Tue, Jun 6, 2023 at 7:36 AM Wei ZHOU wrote: > Hi Will, > > In the advanced zone with security groups, you can only create Shared > networks. L2 and isolated/VPC are not supported. (In my opinion, we could > support L2 as well). > In the advanced zones, you can create Shared/L2/Isolated/VPC, but vms do > not have security groups. > > Advanced zone with SG is suitable for public cloud providers, and advanced > zone without SG is suitable for private clouds. > There is an idea from some years ago, to combine these two types into one, > but not implemented yet. It is very complicated. > > -Wei > > > On Tue, 6 Jun 2023 at 12:45, Will Conrad > wrote: > > > HI Community! > > > > My company is building a cloudstack implementation and have discovered > > that security-group enabled advanced zones seem to function unexpectedly > > differently than non-security-group enabled advanced zones. After > creating > > a security-group enabled advanced zone, when adding new networks to this > > zone, we seem to have lost the choices of "L2" and "isolated". Is this > > normal? Is this the way security groups were designed to function? I did > > read through the documentation for security groups, and noticed the > > "limitations" expressed as well as saw the documentation that VPC are not > > supported in security-group enabled zones. I'm looking for further > > clarification. > > > > As depicted in the below screenshot, "shared" is now the only option > where > > before "L2" and "isolated" were also options. > > > > Have I missed something? Have I misinterpreted something? Is there > further > > documentation that might describe the nuances of using security groups in > > advanced zones? > > > > Any assistance is appreciated. Thank you! > > > > Regards, > > > > Willard Conrad > > DevOps Engineer > > Hivelocity, LLC > > > > [image: image_720.png] > > >
Re: Difference in functionality of Advanced Networking With and Without Security Groups
Hi Will, In the advanced zone with security groups, you can only create Shared networks. L2 and isolated/VPC are not supported. (In my opinion, we could support L2 as well). In the advanced zones, you can create Shared/L2/Isolated/VPC, but vms do not have security groups. Advanced zone with SG is suitable for public cloud providers, and advanced zone without SG is suitable for private clouds. There is an idea from some years ago, to combine these two types into one, but not implemented yet. It is very complicated. -Wei On Tue, 6 Jun 2023 at 12:45, Will Conrad wrote: > HI Community! > > My company is building a cloudstack implementation and have discovered > that security-group enabled advanced zones seem to function unexpectedly > differently than non-security-group enabled advanced zones. After creating > a security-group enabled advanced zone, when adding new networks to this > zone, we seem to have lost the choices of "L2" and "isolated". Is this > normal? Is this the way security groups were designed to function? I did > read through the documentation for security groups, and noticed the > "limitations" expressed as well as saw the documentation that VPC are not > supported in security-group enabled zones. I'm looking for further > clarification. > > As depicted in the below screenshot, "shared" is now the only option where > before "L2" and "isolated" were also options. > > Have I missed something? Have I misinterpreted something? Is there further > documentation that might describe the nuances of using security groups in > advanced zones? > > Any assistance is appreciated. Thank you! > > Regards, > > Willard Conrad > DevOps Engineer > Hivelocity, LLC > > [image: image_720.png] >
Re: IP Spoofing and IP Theft
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 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 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 > .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 >> 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 >> 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 >> > > > Date: Thursday, 18 May 2023 at 1:08 PM >> > > > To: 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 >> > > > >> > > > >> > > > >> > > > >> > > >> > >> >
Difference in functionality of Advanced Networking With and Without Security Groups
HI Community! My company is building a cloudstack implementation and have discovered that security-group enabled advanced zones seem to function unexpectedly differently than non-security-group enabled advanced zones. After creating a security-group enabled advanced zone, when adding new networks to this zone, we seem to have lost the choices of "L2" and "isolated". Is this normal? Is this the way security groups were designed to function? I did read through the documentation for security groups, and noticed the "limitations" expressed as well as saw the documentation that VPC are not supported in security-group enabled zones. I'm looking for further clarification. As depicted in the below screenshot, "shared" is now the only option where before "L2" and "isolated" were also options. Have I missed something? Have I misinterpreted something? Is there further documentation that might describe the nuances of using security groups in advanced zones? Any assistance is appreciated. Thank you! Regards, Willard Conrad DevOps Engineer Hivelocity, LLC [image: image_720.png]
PA and Apache Cloud Stack Integration ( config sync mismatch)
Dear Apache Cloud Stack Team , Good Day As per integration between PA and ACS .. the status is good and config is sync after ACS create Instance But Main problem is Sync Interface config mismatch on PA firewall Let me show some screenshot below Can edit on Apache Cloud Stack [cid:image002.png@01D9988E.EDCB9360] This is default disable and can we edit Best regards , Wai Phyo
