Hacker News Reader

Comment by Animats | Hacker News Reader

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.

View on HN

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.

Those requests seldom get far enough to start significant server activity. It's the ones that look like legit requests that are the problem.

Seldom isn’t good enough. When it comes to security you have to be right 100% of the time. An attacker only has to be right once. Good luck.

That's not true. Security is always a trade-off between effort invested and probability of a possible breach.

There is no 100% secure system.

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.

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."

If the source IP is fake, the request can't get beyond the first packet. Those get filtered out easily. That's Cloudflare's main offering.

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.

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 title of the article does say DDOS, however, which is focused more on saturating bandwidth, not CPU.

Sadly DDoS has at times been used as a blanket term that also includes DoS.

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.

Has anyone seen a 20TB attack?

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.

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.

https://www.cloudflare.com/learning/ddos/famous-ddos-attacks...

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.

Certainly no need for cloudflare

How have you set it up, technology-wise?

Reply on news.ycombinator.com