How Cloudflare blocked a monumental 7.3 Tbps DDoS attack

Original Article ↗ Hacker News Discussion ↗

Legacy protocols & QOTD angle

  • Several commenters learned about or reminisced over the QOTD (Quote of the Day) protocol; some run it privately for fun.
  • Others doubt there are many genuine QOTD servers left and suspect Cloudflare may just be classifying “UDP port 17” traffic as QOTD, possibly over-attributing.
  • QOTD-over-UDP is noted as an easy reflection vector; QOTD-over-TCP or other stateful protocols are less amenable to amplification.

Botnet scale, behavior & attack purpose

  • Commenters note 7.3 Tbps is “just” 7,000 nodes with 1 Gbps uplinks; modern home fiber plus cheap devices (IoT, routers, old PCs) makes that plausible.
  • Typical C2 patterns are discussed: compromised devices polling dummy domains, DNS fast flux, and “botnet-as-a-service” offerings.
  • A 45-second burst is seen as likely a test, “proof-of-capability” for a customer, a misfire, or a short “free sample” attack.

Cloudflare’s role: protection, centralization, and ethics

  • Many view the post as good technical marketing: informative and not oversold.
  • Others criticize Cloudflare for:
    • Shielding DDoS-for-hire sites and other shady services behind its network.
    • Contributing to centralization and making “just put it behind Cloudflare” the default instead of addressing root causes.
  • A few report Cloudflare underperforming on HTTP-level (L7) attacks, especially on free plans, requiring manual rules on their own infrastructure.

Mitigation strategies & where responsibility lies

  • Recurrent suggestions for ISPs:
    • Egress filtering / BCP 38 to prevent source spoofing.
    • Automated detection of abnormal flows (large UDP floods to one IP) and temporary throttling or disconnection.
    • Taking abuse reports seriously instead of ignoring them.
  • Others point out scaling, false positive, and economic issues: ISPs don’t want support load, metering/billing complexity, or to cut paying customers without regulation.
  • Debate over punishing infected-end users (e.g., long-term throttling) vs. holding device makers/retailers accountable; strong disagreement on fairness and practicality.
  • IoT insecurity is widely blamed as a long-term driver of botnets, with skepticism that consumers will ever manage security themselves.

Technical framing of DDoS

  • Distinction emphasized between volumetric L3/L4 attacks (Cloudflare is strong) and L7/app-layer attacks that can bypass or overload origins despite Cloudflare.
  • Some discuss BGP-based blackholing/flowspec as more scalable than “just buy a bigger pipe,” but requiring automation for short attacks.
  • One thread nitpicks the article’s “three decades” phrasing for DDoS history; others dismiss this as unhelpful pedantry.

Disclosure, IPs & “feeding the trolls”

  • Question whether publicizing record attacks gives botnet operators free advertising; others counter that exposing IPs (to networks, not publicly) weakens the botnet.
  • Releasing full IP lists publicly is seen as risky—effectively a target list for re-compromise—though sharing with AS operators or services like AbuseIPDB is noted as common.