If you have some kind of expensive request, use fair queuing by IP address. If someone has a request pending, more requests from the same source go behind IP addresses with fewer requests. So each IP address competes with itself, not others.
For some reason, this isn't done much. I have it on a site of mine. I didn't notice for a week that someone was making a huge number of requests and not even waiting for the task to complete. It didn't hurt anything.
It’s not used because any serious attack is going to come from multiple unrelated sources, think a botnet full of compromised IoT devices hitting your server with 20TB a second worth of requests. So you might as well plan for that scenario instead.
That's an entirely different kind of attack. If your server is being flooded with 20TB/s of traffic, there's nothing you can do on the box itself to fix things. Whatever you do, the legitimate requests won't be able to get through.
If however your DOS attack is an attacker making lower-volume CPU-expensive requests on your site, there's plenty of things to help mitigate the assault.
That's the key difference between a DOS and a DDOS, yes. Since I can't load the OP article on this machine for some reason, I can't review the symptoms described. The title of the article does say DDOS, however, which is focused more on saturating bandwidth, not CPU.
The headline and article itself do indeed (incorrectly) call it a DDOS attack. The attack itself was very much non-distributed, and involved a single malicious actor `curl`ing an expensive API endpoint in a loop.
Only a small percentage of a volumetric attack has to get through to take you down. Also, depending on the attack, they probably all are "legit requests."
This is not true though. Security is about mitigating threat at some cost. There are some threats you can't mitigate cost-effectively. Some are unmitigable at all.
its about layers which includes real security and sometimes trickery. the statement is true though about 100% and the attacker only once but some tack maybe would be in order. there are procedures that can reduce vectors and so minimizing damage and minimizing successes.
true, fq wont solve the problem completely.
but it will solve the elphant- vs. mice-flow problem
i.e. not make your interactive traffic suffer queueing latency from a simultaneous big transfer.
The biggest DDoS attack to date took place in February of 2018. This attack targeted GitHub, a popular online code management service used by millions of developers. At its peak, this attack saw incoming traffic at a rate of 1.3 terabytes per second (Tbps), sending packets at a rate of 126.9 million per second.
Never mind that the units would probably 20tb/s, it wouldn’t be impossible. We saturated our gig ethernet with 8 image upload workers from a flask app. We could have saturated a 20tb line (if such a thing existed) with 160000 workers. I’ve seen bot nets for rent with something like 30k bots. Which means you might be able rent enough machines with enough bandwidth to saturate 20tb/s for maybe $1k/hr. multiply by 8 if you really care about 20TB/s. I do think 20TB starts getting to be big players though, especially since anyone with that much bandwidth is going to have teams dedicated to mitigating these kinds of problems.
And even if you havent had time or knowledge to setup fair queuing, this attack was very light, and an awk logparsing script that append ips to a firewall would have been more then sufficient.
For some reason, this isn't done much. I have it on a site of mine. I didn't notice for a week that someone was making a huge number of requests and not even waiting for the task to complete. It didn't hurt anything.