4 ms·

How does DDoS mitigation work? When people say "I put my website behind Cloudflare to mitigate DDoSes", what does it mean exactly? Is it only about having a la

by sph 3y ago

How does DDoS mitigation work? When people say "I put my website behind Cloudflare to mitigate DDoSes", what does it mean exactly? Is it only about having a large enough ingress pipe that you can weather however many Gb/s you are being bombarded with, and still having some spare capacity for legitimate traffic?

jart 3y ago
You use algorithms like token bucket.
dharmab 3y ago
Often it means automatically recognizing DDoS requests and handling them in a way that is less costly, without impacting legitimate users. In this case, it might mean recognizing when a client rapidly resets streams, and either moving that traffic to a slow lane or filtering it entirely.
richardwhiuk 3y ago
Cloudflare, and other companies, can detect that requests are DDoS and either drop, throttle, or verify the traffic, instead of forwarding it your server. You configure your server to drop all traffic which wasn't set by cloudflare, which is efficient.
SteveNuts 3y ago
When the ddos attack is volumetric, the only way to mitigate it is to have a fat enough network to handle the traffic while you work with ISPs to start blocking the traffic upstream. Not all ddos attacks are based on volume though, some are exploiting native features of a protocol, like the slow loris attack https://www.cloudflare.com/learning/ddos/ddos-attack-tools/slowloris/ https://www.cloudflare.com/learning/ddos/ddos-attack-tools/s...
- dijit 3y ago
  that's not the only way. The way we used to do it is have "filter boxes" with a real anycast IP address's which reverse connect to your origin. This helps a lot because it keeps a lot of traffic localised instead of allowing it to collect in one place. Anycast should also mean you have a failover mechanism; but if it fails then you're only down in one section of the world where the most bots are anyway, which is usually not as bad as being down globally.
jruohonen 3y ago
CDN/SDN.
detaro 3y ago
a) Big pipes b) ability to filter the noise from real traffic as far as possible (i.e. there is little point in taking in a big pipe of DDoS traffic and then just proxying it to the thinner pipe to the real backend - but if you can identify bad traffic you can drop it and not pass it through). c) being a CDN helps as a side-effect (what the CDN serves doesn't load the backend services, what can be served from the CDN works for users even if the backend is slow or down)
MayeulC 3y ago
It is about that and a lot of other things, but it usually involves being able to dynamically scale up your bandwidth and compute power to cope with the incoming flood. A lot of DDoS traffic isn't actual HTTP traffic, it can be garbage targetted at your IP address to "fill the pipes" (bigger pipes help, as well as having multiple server geographically distributed). Some can be TCP SYN flood, to just open TCP connections and exhaust available ports. Etc. Oftentimes, multiple simple reverse proxies can handle these malformed requests in front of your server. Then, for the most sophisticated queries that send seemingly-legitimate HTTP traffic, one has to handle them... It could be serving requests from a cache, adding captchas to slow attackers and identify legitimate traffic, enforcing rate limits, etc. Usually, you'd like to be able to tell if a request is legitimate or not before forwarding it to the actual server, and you can deploy all sorts of tools to do so.
- toast0 3y ago
  > it usually involves being able to dynamically scale up your bandwidth and compute power to cope with the incoming flood. I don't think this is right. If you have a meaningful amount of bandwidth, dynamically scaling it is getting a connection upgraded in weeks instead of months. If you don't have a meaningful amount of bandwidth, you're rely on your provider(s) to have enough bandwidth and again, they can't expand quickly. > Some can be TCP SYN flood, to just open TCP connections and exhaust available ports. If you have a tcp stack from maybe 2003 or later (so excluding macos, unless they changed something in the past four years), it will have synflood protection, with syncookies. In the event of a heavy synflood, your system will send at most one syn+ack per incoming syn, and actually accept connections on the incoming ack. Yes, you miss out on detailed tcp options, but it's not that big of a deal, unless the volume impacts your available bandwidth. Also, as a tcp server, you can't meaningfuly run out of ports; your one listen ip:port can connect to all ip:ports, if you have the memory for it. You'll probably run out of total accepted sockets, but there's no real resource limit on partially accepted connections, because of syncookies. It can be much more draining when DDoS clients actually hold connections. But it's often simply about volumetrics, and it's easier to generate a high volume of SYN packets than to hold a connection.
papichulo2023 3y ago
I always believed that they have some secret mega routers with massive computation limits that allows smart and complex tcp/udp packages filtering.
- sschueller 3y ago
  They do have special equipment at the edges like: https://www.netscout.com/arbor https://www.netscout.com/arbor
tazjin 3y ago
Back when I was in Google SRE, people would joke that "we just send DDoS traffic to Australia". In general, Google's internal cross-DC traffic is so much larger than anything anyone could DDoS them with that they can always find a way to deal with it.

by sph 3y ago

jart 3y ago

You use algorithms like token bucket.

dharmab 3y ago

Often it means automatically recognizing DDoS requests and handling them in a way that is less costly, without impacting legitimate users. In this case, it might mean recognizing when a client rapidly resets streams, and either moving that traffic to a slow lane or filtering it entirely.

richardwhiuk 3y ago

Cloudflare, and other companies, can detect that requests are DDoS and either drop, throttle, or verify the traffic, instead of forwarding it your server. You configure your server to drop all traffic which wasn't set by cloudflare, which is efficient.

SteveNuts 3y ago

When the ddos attack is volumetric, the only way to mitigate it is to have a fat enough network to handle the traffic while you work with ISPs to start blocking the traffic upstream. Not all ddos attacks are based on volume though, some are exploiting native features of a protocol, like the slow loris attack https://www.cloudflare.com/learning/ddos/ddos-attack-tools/slowloris/ https://www.cloudflare.com/learning/ddos/ddos-attack-tools/s...

dijit 3y ago
that's not the only way. The way we used to do it is have "filter boxes" with a real anycast IP address's which reverse connect to your origin. This helps a lot because it keeps a lot of traffic localised instead of allowing it to collect in one place. Anycast should also mean you have a failover mechanism; but if it fails then you're only down in one section of the world where the most bots are anyway, which is usually not as bad as being down globally.

jruohonen 3y ago

CDN/SDN.

detaro 3y ago

a) Big pipes b) ability to filter the noise from real traffic as far as possible (i.e. there is little point in taking in a big pipe of DDoS traffic and then just proxying it to the thinner pipe to the real backend - but if you can identify bad traffic you can drop it and not pass it through). c) being a CDN helps as a side-effect (what the CDN serves doesn't load the backend services, what can be served from the CDN works for users even if the backend is slow or down)

MayeulC 3y ago

It is about that and a lot of other things, but it usually involves being able to dynamically scale up your bandwidth and compute power to cope with the incoming flood. A lot of DDoS traffic isn't actual HTTP traffic, it can be garbage targetted at your IP address to "fill the pipes" (bigger pipes help, as well as having multiple server geographically distributed). Some can be TCP SYN flood, to just open TCP connections and exhaust available ports. Etc. Oftentimes, multiple simple reverse proxies can handle these malformed requests in front of your server. Then, for the most sophisticated queries that send seemingly-legitimate HTTP traffic, one has to handle them... It could be serving requests from a cache, adding captchas to slow attackers and identify legitimate traffic, enforcing rate limits, etc. Usually, you'd like to be able to tell if a request is legitimate or not before forwarding it to the actual server, and you can deploy all sorts of tools to do so.

toast0 3y ago
> it usually involves being able to dynamically scale up your bandwidth and compute power to cope with the incoming flood. I don't think this is right. If you have a meaningful amount of bandwidth, dynamically scaling it is getting a connection upgraded in weeks instead of months. If you don't have a meaningful amount of bandwidth, you're rely on your provider(s) to have enough bandwidth and again, they can't expand quickly. > Some can be TCP SYN flood, to just open TCP connections and exhaust available ports. If you have a tcp stack from maybe 2003 or later (so excluding macos, unless they changed something in the past four years), it will have synflood protection, with syncookies. In the event of a heavy synflood, your system will send at most one syn+ack per incoming syn, and actually accept connections on the incoming ack. Yes, you miss out on detailed tcp options, but it's not that big of a deal, unless the volume impacts your available bandwidth. Also, as a tcp server, you can't meaningfuly run out of ports; your one listen ip:port can connect to all ip:ports, if you have the memory for it. You'll probably run out of total accepted sockets, but there's no real resource limit on partially accepted connections, because of syncookies. It can be much more draining when DDoS clients actually hold connections. But it's often simply about volumetrics, and it's easier to generate a high volume of SYN packets than to hold a connection.

papichulo2023 3y ago

I always believed that they have some secret mega routers with massive computation limits that allows smart and complex tcp/udp packages filtering.

sschueller 3y ago
They do have special equipment at the edges like: https://www.netscout.com/arbor https://www.netscout.com/arbor

tazjin 3y ago

Back when I was in Google SRE, people would joke that "we just send DDoS traffic to Australia". In general, Google's internal cross-DC traffic is so much larger than anything anyone could DDoS them with that they can always find a way to deal with it.