DDoS (Distributed Denial of Service) attacks are at their core near identical to perhaps more common DoS (Denial of Service) attacks, with one major difference in DDoS being, well, distributed. What that means though is that the attacker(s) will use multiple locations as a source of their attacks on your infrastructure, but more importantly, just like with DoS attacks, the attacker(s) will in both cases try to exhaust your infrastructure's resources. This is where booth DDoS and DoS might be the same, and is important to understand.
So, exhausting your infrastructure resources. What could that mean and how would an attacker do that? It turns out there are many ways to cause servers and other networking equipment to have more work with preparing and responding to external requests, than the attacker's own setup (distributed or not) would permit. So this is where the attacker takes the advantage - it is cheaper for him to send requests, than for you to respond to them. Given enough attack oomph by whichever means, one stronger adversary (DoS), or many weaker but greater in number ones (DDoS), your server's resources will be exhausted and cause denial of service to any other, legitimate traffic. Some of these techniques would be traceable to the individual Virtual Host responding on a certain HTTP(S) location, and others might rather target the infrastructure more directly and on lower levels, maybe the transport layer itself by abusing network protocols, both causing too many responses to be required than the infrastructure can handle.
So here's are two clues here:
- The DDoS attack your provider mentions had to have been on the high level stack that would identify a virtual server in its requests, like for example on the HTTP(S) stack and requesting URLs pointing to your virtual server, and
- Whichever resource was continuously requested caused the server your Virtual Host was hosted on to exhaust its resources by preparing a response. That could be any of the number of resources your VPS server had a limited supply of, or any of their combinations, like maybe continuously reaching local storage quota, system's memory, CPU cycles, e.t.c.
This might seem clear cut, but bear with me, because it really isn't in your case. Here's the thing; You mention you hosted your website on a VPS (Virtual Private Server), so in theory, all the resources your VPS server could have exhausted shouldn't have translated to any problems with other VPS's on the same physical hardware hosting them (i.e. it's supposed to be a Virtual Machine and isolated from any other VM's) and you have actually been paying to your provider maybe a monthly fee to use all those resources to your liking, as long as you're respecting their ToS (Terms of Service). And for any DDoS attempts to have directly identifiable target on this VPS/VM stack, their requests would have to be on the highest stack actually requesting a network domain (let's say it was on the HTTP(S) protocol, which would make it URLs then, for the sake of argument) and including enough information for the VM host to decide to which VM client (your VPS) to redirect requests to.
So we have this conundrum of either/or:
- If the problematic requests were on the HTTP(S) stack and including identifiable request URLs, then this shouldn't cause any problems to your VPS host, but it would exhaust your VPS resources, something that you were paying for anyway, and
- If the problematic requests were on the lower, network layer on the TCP/IP stack, then they wouldn't necessarily (and why would they?) include information in the request packets which specific VPS client they were targeting.
So this can only be answered in two ways:
- Your VPS was actually the only VM that was hosted on the same IP address, and your provider could conclude your services were a target of DDoS attack like so, or
- Your VPS provider is full of s***
Most likely though, you will never know which one of the two options was really the case. If it's all the same to you by now, you can post your IP and domain name in the comments below, and I'll check if there are any conclusive indications to be found in the various databases / resources on the Internet which of the two options might be more likely, but unless you get a full disclosure by anyone with direct access to the physical server in question, it will remain a mystery. It's up to you to decide, if you can deal with such unknowns and how much you're prepared to pay monthly to have this service, but I know which route I'd choose. Just saying... ;)