How to prevent VPS users from changing allocated IPs?

How to prevent VPS users from changing allocated IPs?
Not sure where this thread belongs, apologies if this is the wrong forum.
++++++++++++++
list of top cheapest host http://Listfreetop.pw

Top 200 best traffic exchange sites http://Listfreetop.pw

free link exchange sites list http://Listfreetop.pw
list of top ptc sites
list of top ptp sites
Listfreetop.pw
Listfreetop.pw
+++++++++++++++

Seems like a huge risk where an errant VPS user could change his IP to a different IP like the gateway and take down the full network?

I've noticed that XenOrchestra has a feature to lock IPs but I can't find the option in XenServer/XCP-ng so I assume it must be a XO specific thing? Unfortunately, XO doesn't link with the popular billing software.

I've also not managed to find an option with Proxmox which is the preferred deployment software.
Well - no, that's not how that works.

Reminder: Routing, especially when it comes to a gateway address, doesn't care a lick what your IP address is, because it only sends to the MAC address of that gateway. They can try spoofing that - but in practice it isn't going to work since then it becomes a race condition as to which interface sees packets for that MAC first - the gateway or the VM.

Your gateway is going to win that race 100% of the time.

If the VPS tries to assign itself the gateway IP or spoofs its MAC address the only thing they succeed in doing is knocking themselves offline. It is not nor should it be much of a concern for you.

Xen Orchestra's VIF locking (which, yes, is available in XenServer) isn't about security concerns like yours, at least not to that extent. It's about not permitting VMs to utilize more resources than they may have purchased, since other IPs within the same CIDR would be fair game to any VM in that block.

So grabbing the gateway IP isn't going to be a concern for you but perhaps assigning themselves other, unused IPs in that same IP range could be done.

In $YEARS of selling VMs we've never seen anyone try and change their IP info or steal IPs they were not assigned - except entirely by accident.

Bad Actors already have what they want if they have a functioning VM - they're not going to start doing things that draws attention to themselves if they can help it.

bitcoins mining and badlist
serversworld.org
hosting his presence
1 hosting 2 domain
inventivehosting.co.uk
hosting r code
host with the most
residualincomeinabox.biz

"I've seen spam you people wouldn't believe. Routers on fire off the OCs of AGIS. I watched MXes burning in the dark near the Cyberpromo Gateway. All those moments will be lost in time, like tears in rain. TTL=0."
Thank you for the reply. I have a slightly better understanding now. Some follow up questions:

1. Are you allocating IPs via DHCP? What is the backend responsible for this?
2. How do you protect against VMs adding more IPs than they were allocated? Do you have tools to detect IPs being used that have not been allocated or do you rely on feedback by the customer that finds out his IP is already in use?
Nope. Statics only.
2. How do you protect against VMs adding more IPs than they were allocated?
We don't. In my original reply I mentioned that we've never had anyone try it, so there's never been a need to engineer against it.

We've had clueless newbies trash their network configuration accidentally but all they ever accomplished was to knock their own VM offline. No one has ever tried to allocate to themselves IPs they were not already authorized to use.

You are wringing your hands over an extremely low probability event. People who are Up To No Good (and not the fun kind like in Hogwart's) do not want to draw attention to themselves and that's a pretty fast way of doing that. They want to fly under the radar and do their nefarious deeds without you noticing them.
"I've seen spam you people wouldn't believe. Routers on fire off the OCs of AGIS. I watched MXes burning in the dark near the Cyberpromo Gateway. All those moments will be lost in time, like tears in rain. TTL=0."
We don't. In my original reply I mentioned that we've never had anyone try it, so there's never been a need to engineer against it.

We've had clueless newbies trash their network configuration accidentally but all they ever accomplished was to knock their own VM offline. No one has ever tried to allocate to themselves IPs they were not already authorized to use.

You are wringing your hands over an extremely low probability event. People who are Up To No Good (and not the fun kind like in Hogwart's) do not want to draw attention to themselves and that's a pretty fast way of doing that. They want to fly under the radar and do their nefarious deeds without you noticing them.
Do you mind sharing what you use to manage the IP space? I'm exploring Proxmox right now and I don't see the option to add an IP address to the NIC when creating a VM.

If the VPS goes offline due to a bad config, how do you restore access to the customer? Do you have some sort of rollback tool available or do you have to intervene manually?

You don't need to be attempting DDoS to want to use more IPs than allocated, some people might take joy in using 10 IPs when only paying for 1, no?

Would you isolate each VM traffic in their own VLAN?

Thanks again for the replies!
VLANs may work to block usages of IPs that a client should not be using. I believe openstack has ACL type setups for IPs also but have not looked to much at that. Networking is fun.
If the VPS goes offline due to a bad config, how do you restore access to the customer? Do you have some sort of rollback tool available or do you have to intervene manually?
Console is your friend. Either you or if you had available, they could console to the VM and fix the network config issue. For example, with proxmox usage of KVM, you open VM manager in ubuntu, connect to the master, double click the VM and you're greeted with the console. The console requires no networking beyond the master's network to function in this case .
This doesn't seem very efficient to be manually restoring the network for a customer's mistake. Is there a way the customer can restore it themselves?
VLANs may work to block usages of IPs that a client should not be using. I believe openstack has ACL type setups for IPs also but have not looked to much at that. Networking is fun.
Until you run out of VLANs? How would you route traffic between VMs? Through the gateway?
This doesn't seem very efficient to be manually restoring the network for a customer's mistake.
Unless you know precisely how they went about breaking it then you can't actually automate the fix for it, can you?

Someone has to go in and at the console figure out "OK buddy, what the hell did you do here?" ... because you can't even know that it's really a broken network configuration until you get into the machine and start poking around in it.

Quote Originally Posted by webhost4all  View Post
Is there a way the customer can restore it themselves?
They have access to the exact same console - the difficulty is they're the ones making the mistakes, aren't they?

If they have to ask us to fix it and they don't have a management plan then we're gonna bill 'em admin time for that.
"I've seen spam you people wouldn't believe. Routers on fire off the OCs of AGIS. I watched MXes burning in the dark near the Cyberpromo Gateway. All those moments will be lost in time, like tears in rain. TTL=0."
Unless you know precisely how they went about breaking it then you can't actually automate the fix for it, can you?

Someone has to go in and at the console figure out "OK buddy, what the hell did you do here?" ... because you can't even know that it's really a broken network configuration until you get into the machine and start poking around in it.

They have access to the exact same console - the difficulty is they're the ones making the mistakes, aren't they?

If they have to ask us to fix it and they don't have a management plan then we're gonna bill 'em admin time for that.
Ah yes, that makes sense if you bill them for the time spent fixing it. How do you usually proposition the extra charges? Before working on it? Or after fixing it?

Another unrelated question, should HVs have public facing IPs with iptables only allowing the billing platform and a management VM or private facing IPs with a VPN tunnel through a management VM?
If you are all Xen, you could use Open vSwitch as your network bridge--you could drop some rules into the flow tables to prevent tenants from using resources that do not belong to them.

It's somewhat involved, but it does work!

Check out nw_dst, nw_src, and dl_dst match criteria in the Open vSwitch ovs-ofctl docs!