How Cloudflare blocked a monumental 7.3 Tbps DDoS attack

(blog.cloudflare.com)

265 points methuselah_in | 1 comments | 20 Jun 25 18:34 UTC | HN request time: 0.21s | source

Show context

londons_explore ◴[24 Jun 25 13:40 UTC] No.44366154[source]▶

A DDoS gets some fraction of the entire internet to attack a single host.

As the internet gets more users and more devices connected, the ratio of DDoS volume to a single connections volume will only get larger.

Is there any kind of solution?

replies(8): >>44366248 #>>44366352 #>>44366379 #>>44366623 #>>44366811 #>>44366991 #>>44367206 #>>44369906 #

sybercecurity ◴[24 Jun 25 13:59 UTC] No.44366352[source]▶

>>44366154 #

Apparently no solution that has gained traction, and no single solution that works everywhere. Source address filtering (BCP 38) got us part of the way, but it's difficult/undesired to do in data centers.

IoT devices (speculated to be used here) would have to have a solution upstream. Things like MUD (RFC 8520) have been proposed, but have problems too - developers need to be able to list all communications of their device and make that available somehow (MUD profile server). Some consumers will never do it on their own, and may want to prevent alerting a device manufacturer they have a device (think connected adult toy...).

Also given that IoT devices may never be updated by their owners, expect to see IoT botnet DoS attacks for years.

replies(1): >>44385937 #

1. citrin_ru ◴[26 Jun 25 10:20 UTC] No.44385937[source]▶

>>44366352 #

> Source address filtering (BCP 38) got us part of the way, but it's difficult/undesired to do in data centers.

BCP 38 is applicable in the DC environment, especially between an operator (hosting/cloud provider) and the customer. Where it is from hard to not practical to use is the network backbone and link between different ISPs. But that's would be a minor problem if BCP 38 will be applied to all stub networks.

↑