2 ms·

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 incomin

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.

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.