[ahmedfromtunis]

> With horrible grammar

Ah, the days before ChatGPT!

On a more serious note, do you think there will ever be a way to stop ddos attacks once and for all?

While all threats are bad, ddos is the most lame type of attacks there is; no special skill or knowledge are needed, just load a script or, heck, pay someone who'll execute it for you as a service.

[tgsovlerkhgsel]

It's not as simple as "loading a script" - IP addresses (or in the case of IPv6, subnets) are (for the average person) a limited resource, as is bandwidth, and most amplification attacks require IP spoofing which is not possible from most connections.

If it's a volumetric attack, the side with more bandwidth wins (the attacker may be able to amplify here). If it's a load-based/application-level attack, blocking the attacker IPs at the firewall level solves it. This was application level, not (purely) volumetric, since they already had a WAF/Cloudfront.

Identifying attacker IPs to block is a matter of correctly attributing cost to a source IP, correctly attributing benefit (i.e. legit user activity) to a source IP, then blocking the IPs or ranges where the cost significantly exceeds the benefit you see from that IP or range.

That's easier said than done, since cost can come in many forms (e.g. open connections clogging up memory, TLS handshakes, requests that are expensive to parse for your web server, requests that trigger expensive database queries, in/out bandwidth, ...) which is why most just slap Cloudflare (or here, Cloudfront) in front of it and work around with manual rules like in this example.

[flafla2]

Cloudflare does a pretty good job of managing it, at the cost of some centralization.

It would be pretty cool if there was a way to DDOS-harden at the protocol layer. Not sure if that’s even possible though

[toast0]

There's application level DDoS, which you generally stop by not doing expensive work for clients that haven't done expensive work for you. Sometimes, easier said than done.

And then there's volumetric DDoS. You can stop this by having more bandwidth than everyone else... but that's pretty hard and it makes you a potential attacker.

Innovation here is in the form of using BGP to disseminate traffic filters. Null routing is the MVP here: this IP is being attacked, so drop traffic to it as soon as possible. But I've seen there's some systems with more precision, like drop udp, drop fragments, drop packets to/from udp/tcp port X.

Most of these systems are designed so that these specialized routes don't propagate beyond immediate peers, but potentially, it might be desirable if they did.

[kijin]

> Null routing is the MVP here: this IP is being attacked, so drop traffic to it as soon as possible.

Oh, this poor guy is being DDoS'd, so we're going to make sure that their service remains denied.

Null-routing the target IP helps everybody except the customer who is being attacked: namely, the network operator and their other customers. From the victim's point of view, it's just as frustrating as the attack itself, and gets in the way of troubleshooting.

With modern tooling and a bit of ML, it shouldn't be too hard for multiple ISPs to collectively determine which IPs are currently part of a large botnet. Drop packets from them, not to the victim. DoS the ones who are causing the DDoS.

[toast0]

> Null-routing the target IP helps everybody except the customer who is being attacked: namely, the network operator and their other customers. From the victim's point of view, it's just as frustrating as the attack itself, and gets in the way of troubleshooting.

If you're running on a single IP, yes. If you're running on multiple IPs, it's not that bad for the one that's being attacked to get its traffic dropped and everything else works. It's not great, but what are you going to do. If you've got enough traffic to overwhelm the inbound on the top of rack switch your box is on, you're not going to be able to really serve any of the good traffic anyway.

> With modern tooling and a bit of ML, it shouldn't be too hard for multiple ISPs to collectively determine which IPs are currently part of a large botnet. Drop packets from them, not to the victim. DoS the ones who are causing the DDoS.

There's usually way too many source addresses to do that, and anyway, routing infrastructure is geared towards looking at destination addresses, not source addresses. Also, each individual source doesn't look that bad --- if I've got 10,000 sources each sending me 1 Mbps of garbage, nobody is going to accept a block for only 1 mbps of sending, and yet, there's 10 Gbps of garbage arriving at my box; if I've got 10 Gbps or better connectivity, no big deal. But, if I'm only on 1 Gbps, I'm getting less than 1 in 10 of my inbound packets. I'd argue, if everything else has a big enough connection, it's probably still no big deal, it should be able to drop packets headed to me, as long as its upstream connection isn't filling up. But once abuse is causing contention that impacts others on my rack, it's probably time to null route.

If it's one of the big botnets with 100,000+ compromised systems, the individual bandwidth is even less. And if the botnet has significant ability to deliver spoofed traffic, source based filtering is meaningless. If it's reflected DDoS, I dunno --- there's value in hunting down the chargen services and removing them from the internet, but that's usually a lot more work.

OTOH, look on the bright side, if your outbound bandwidth is high and you get a lot of inbound DDoS, you may have roughly balanced your usage, and you may qualify for settlement free peering! (IMHO, this has got to be a major part of Cloudflare's business plan)

[xorcist]

So the suggestion here is to implement source routing on a whim, with a table of 100+k entries? At your peering point?

An ISP has to do what it has to do to save their business when a large attack hurts their business. This may be what the attacker wants but that's not an excuse to do nothing.

But what machine learning has to do with this is not clear. Null routing protects you against traffic volume. Machine learning sounds like it maybe can help diagnose more sophisticated low-volume attacks. Maybe. You don't want anything remotely compute intensive when mitigating attacks.

[squarefoot]

>> With horrible grammar

> Ah, the days before ChatGPT!

The topic made me read that as CatGPT, and now I can't pull it out of my head.

[zbyszek]

https://catgpt.wvd.io/

[bee_rider]

Maybe if the network was much more distributed and lower bandwidth?

If most of your customers are in Mexico, Canada is DDoSing you, and the pipes between you and Canada start filling up as a result that isn’t a big problem, right? As long as consumer routers on you/Mexico’s side of the Canadian clog don’t decide to help out.