Seems counterproductive, even. I would expect a request that causes a 400 response to be rejected early, whereas a request with a valid payload would go through more processing and be more expensive.
To me what it means is that the attacker figured out some custom call to the application that is probably expensive for the app to deal with and can easily cause a denial of service.
It'd be pretty rare for the application to return error 400, generally that's something that the server would be spitting out when it fails to parse the HTTP request.
That could suggest random urls. But it could be anything really depending on the app. I'm coming around to your pov that it is not descriptive. Something about the layer 7 flood was causing the app to respond with 400s and that's what Linode started calling it. But it doesn't help us understand anything about it.
It wouldn't suggest a flood of random urls, error 400 is generally a response from the webserver when it receives a request it can't understand (e.g not HTTP).
A request like that would never hit the web application as the server wouldn't know what to do with it.
see:
echo ":P"|nc linode.com 80
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>
I agree that it's not descriptive, but 400 isn't just for malformed HTTP – it covers malformed requests in general. So there's lots of opportunity for this to get past the basic HTTP processing of the web server and into the application code.
For instance, if they had a web service to reboot a server that takes a numerical ID for an argument, but somebody passed in something other than digits – it's valid HTTP, so it would get past the HTTP level and into the application code.
Presumably the attackers found areas that cause very expensive 400 failures for Linode at the application level. If I remember correctly, their web infrastructure is currently legacy Coldfusion and in the process of being rewritten. They might not have the agility/human resources to patch up these kinds of problems quickly, given the ongoing transition.
