How can cloud service providers know that they are being used for launching a DoS?

Question

Can cloud service providers like Amazon, Microsoft etc. detect that they are being used to launch a DoS/DDoS against any target? If yes, how?

I am guessing that if they attack a single machine, a good IDS can detect it. My doubt here is, can the IDS detect a scenario where the cloud system spoofs the IP address and floods several different machines to DoS the target. On a similar note, can the cloud service provider detect if it's hosted machines are being used in botnets?

Source of inspiration: http://www.networkworld.com/article/2858874/cloud-computing/sony-may-have-used-amazon-s-cloud-to-launch-a-counter-dos-attack-after-its-breach.html

Answer 1

First of all, IP spoofing can and should be detected and blocked. The provider's firewalls shouldn't allow packets that have a source IP different from the legitimate netblocks assigned to the server, and raise an alert as IP spoofing is a pretty reliable indicator that some idiot is trying to use the server for DoS or similar nefarious things (I can't think of any legitimate use case for IP spoofing).

For simple bandwidth-exhaustion DoS, assuming the former method didn't catch it, the provider can try to detect common indicators such as whether the packets correspond to any known DoS tool or malware, whether packets are similar (1Gb/s of exactly the same UDP packet seems suspicious for example), and can finally apply advanced neural-network based pattern matchers that try to look for anything unusual just like banks do for credit cards (a server who never sends out much traffic suddenly sends out 1Gb/s -> raise an alert).

For higher layer attacks such as HTTP, etc I do not see much solutions I'm afraid. The first issue is a legal and ethical one. Comparing the source/destination, size and entropy of packets (as described above) is one thing and personally I would be fine with it, on the other hand having a proxy that would try to parse any packet sent out and break it down into a list of HTTP headers, DNS requests, etc is another thing and would be equivalent to wiretapping and besides being potentially illegal, I bet most people wouldn't like it, even if it is used for legitimate purposes (but once you get the potential to parse and understand any packet, it's only a matter of time before someone decides logging that data for whatever reason).

Assuming the legal/ethical concerns are out of the way, it would be really difficult to tell legitimate and malicious packets apart. There are some applications that can be brought down with just a handful of requests to the search form with the right query. How will a system like this tell legitimate search form usage from malicious abuse?

In my opinion, higher-layer attacks are best dealt with at the attack's recipient, as only they can tell a malicious request from a legitimate one, and can easily implement countermeasures on their own, as opposed to bandwidth exhaustion attacks where cooperation of the attacking network's provider is necessary since getting enough bandwidth to sustain an attack is sometimes impossible for a medium-sized company given a large enough botnet.

Answer 2

They can easily enough set up monitoring for big changes in bandwidth usage to/from a large number of hosts, but more likely for this scenario if someone's being attacked they'll report the abuse, at which point the amazon csirt-equivalent team knows its not legitimate traffic and can play whackamole with the accounts behind it.

For the most part, abuse happens, and the onus isn't on these companies to prevent it in the first-place so much as respond appropriately when it's reported, in the current state-of-play. Respond-appropriately though should mean that repeated attacked with the same M.O. should not happen.

Answer 3

One very common way to detect this is to use a netflow analyser to do traffic analysis. No doubt these large networks have this in place. With netflow you can collect specific characteristics of inbound and outbound traffic, including source and destination IP addresses, traffic volume, protocol and protocol specific information (for example source and destination port).

A netflow analyser will take this data and do analysis on them, which can be used to detect anomalies, including information like top source and destination IP addresses (both in number of packets/sec and bytes/sec), and top source and destination ports.

Many netflow analysers include anomaly detection and offer alerting based on these traffic characteristics. So, for example, you can use them to signal if there's an abnormal amount of traffic coming from UDP/53 towards one specific IP address, or if the total amount of traffic from all IPs in the network towards one specific address is above set limits. Spoofed addresses can also be deteected this way.