Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jerks on the Internet: what my first DDoS taught me

sergiomattei.com

Post reply on HN
Print view View original

41–50 of 95 posts

Re: Jerks on the Internet: what my first DDoS taught me

#41

Post by toast0 »

fxfan wrote: post #29

Does anybody have experience in getting DDOS'd? All i see are 3 ip addresses (offending) in the screenshot and it makes me wonder how many is typical? I have never been ddos's and all I ever receive are failed ssh attempts with simple passwords. Pretty much the easiest thing to tackle. But I'd love to know from DDOS'd people how their attacks looked? From cloudflare logs all I see is a single IP address being blocked…

I've gotten a good number of DDoSes sent my way. For the ones I've noticed, there's usually pretty good IP diversity. Volumetric attacks are either like tcp syn floods, spoofed from everywhere, or udp reflection spoofed from you to reflecting hosts, which have pretty good diversity. If you want to survive these, you need to have either a big connection, or packet filtering by someone with a big connection. As of a few years ago, 10Gbps was enough to ignore casual attacks, as long as your IP stack is up for it -- you may need to do a bit of tuning and make sure you've got recent syn handling. On the other hand, if you're running a 10Gbps connection, be sure you're not a reflection target -- be extremely careful about running UDP servers that send significantly larger replies than the requests, if they're exposed on public ips.

Layer 7 attacks are different; you can't spoof those, so you don't get perfect distribution -- but there are lots of ways to distribute simple requests. If the requests are coming from a botnet, there's usually a lot of control about what the requests look like, but if they're coming in through tricking other software (which is unfortunately common), then at least you'll likely have some identifying information; it's dumb to block things by user-agent, but it can be pretty effective. The way to handle these is really to try to make sure the effort your server spends is roughly on par with the effort the client spends; and try to make sure you're running the best optimized TLS handshakes you can (ECC certs are easier on servers than RSA).

Re: Jerks on the Internet: what my first DDoS taught me

#42

Post by kristiandupont »

jmchuster wrote: post #40

Hope 10% of this might be useful to you. 1) the three most important metrics for any endpoint are error rate, lantency, throughput. So i hope you've learned to not be surprised that abnormal throughput (either via ddos attacks or friendly n+1 queries) is a common error condition. 2) banning ip addresses is useless and often counter productive. If possible, short-circuit requests from an ip so you can isolate them and…

>short-circuit requests from an ip

What does that mean?

Re: Jerks on the Internet: what my first DDoS taught me

#43

Post by zoul »

kristiandupont wrote: post #42
jmchuster wrote: post #40

Hope 10% of this might be useful to you. 1) the three most important metrics for any endpoint are error rate, lantency, throughput. So i hope you've learned to not be surprised that abnormal throughput (either via ddos attacks or friendly n+1 queries) is a common error condition. 2) banning ip addresses is useless and often counter productive. If possible, short-circuit requests from an ip so you can isolate them and…

>short-circuit requests from an ip What does that mean?

I’d guess serving them a static placeholder or cached result to prevent them from hammering the DB?

Re: Jerks on the Internet: what my first DDoS taught me

#44

Post by Animats »

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.

Re: Jerks on the Internet: what my first DDoS taught me

#45

Post by veryworried »

Animats wrote: post #44

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…

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.

Re: Jerks on the Internet: what my first DDoS taught me

#46

Post by Animats »

veryworried wrote: post #45
Animats wrote: post #44

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…

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.

Re: Jerks on the Internet: what my first DDoS taught me

#47

Post by veryworried »

Animats wrote: post #46
veryworried wrote: post #45

Earlier quoted context omitted.

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.

Re: Jerks on the Internet: what my first DDoS taught me

#49

Post by samoa42 »

veryworried wrote: post #45
Animats wrote: post #44

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…

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.

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.
Post reply on HN