[HN Gopher] Record DDoS pummels site with once-unimaginable 7.3T...
___________________________________________________________________
Record DDoS pummels site with once-unimaginable 7.3Tbps of junk
traffic
Author : Brajeshwar
Score : 57 points
Date : 2025-06-21 12:56 UTC (10 hours ago)
(HTM) web link (arstechnica.com)
(TXT) w3m dump (arstechnica.com)
| smokel wrote:
| _> A total of 34,500 ports were targeted, indicating the
| thoroughness and well-engineered nature of the attack._
|
| How is that more complicated than a for-loop?
| ukuina wrote:
| Because it's a _distributed_ for loop?
| lolinder wrote:
| Not necessarily. It could be one for loop running on tens of
| thousands of compromised IoT devices, with the only thing
| distributed being the command that starts the loops.
| saulpw wrote:
| Sounds like you've never managed tens of thousands of nodes
| in a distributed system. It's not trivial.
| jjtheblunt wrote:
| (elixir / otp says "hold my beer")
| luckylion wrote:
| What would making a C&C server for a botnet hard? It's
| not like you need to carefully coordinate all those
| clients to hit precise timings, you just tell them who to
| target and let them rip, don't you?
| PcChip wrote:
| Nothing. I did it with IRC servers in the late 90s when I
| was a dumb kid in high school
| blitq wrote:
| It's not :)
| monster_truck wrote:
| You can't just spray every port blindly if you are maximally
| trying to disrupt, there is nuance to it.
| lolinder wrote:
| Right. So why does the fact that they targeted 34,500 ports
| show it was a well-engineered attack? By itself it's just
| evidence that they know how to iterate over ports. Coupled
| with the data size (7.3Tbps) we know they had an enormous
| botnet. None of this points to a well-engineered attack, it
| just means that lousy IoT has made botnets incredibly cheap.
|
| A well-engineered attack would not draw headlines for its
| scale because it would take down its target without breaking
| any records.
| motorest wrote:
| > A well-engineered attack would not draw headlines for its
| scale because it would take down its target without
| breaking any records.
|
| You don't hear much about DDoS that are either comparable
| in size or bring down targets. How do you explain why this
| one made the news in spite of not having met your arbitrary
| and personal bar?
| lolinder wrote:
| Like I said: it broke records for data throughput. It
| doesn't hurt that Cloudflare has an interest in
| publicizing the size of the DDoS attacks it fights off.
|
| > in spite of not having met your arbitrary and personal
| bar?
|
| I'm not sure what you mean by this. I didn't establish
| any sort of bar for what sorts of DDoS should get
| headlines, I'm just agreeing with OP that that line in
| the article doesn't make any sense. There may be other
| reasons to believe this attack was well-engineered but
| the article doesn't get into them.
| balanc wrote:
| Doesn't Cloudflare have every incentive to inflate the bandwidth
| of the attack they have successfully mitigated?
|
| And yes I know that there are Cloudflare employees here so spare
| me with your pinky swears.
| x2tyfi wrote:
| Couldn't this logic apply to basically every internal metric
| across every company?
| move-on-by wrote:
| A couple months ago Brain Krebs, who uses Google's Project
| Shield, wrote of a very similar attack. 6.3 terabits, all UDP,
| less then a minute.
|
| https://krebsonsecurity.com/2025/05/krebsonsecurity-hit-with...
| ksec wrote:
| If I dont want my user to have Cloudflare captcha or for example
| captcha dont work on my Safari 18.5 running on OpenCore Patcher
| MacBook 2015. What other options have I got?
| nemathod wrote:
| GRE-Tunnel
| VladVladikoff wrote:
| I'm confused what this would accomplish? Do GRE tunnels drop
| UDP packets or something?
| firebird84 wrote:
| You make a contract with a company that does layer 3 ddos
| protection, you advertise a route including their AS on a
| subset of your prefixes and they route to you over a GRE
| tunnel.
| VladVladikoff wrote:
| Sorry for the noob questions here but why couldn't you
| just firewall? ie only allow traffic forwarded from the
| DDOS proxy?
| immibis wrote:
| With these services the forwarding happens at a lower
| level. The traffic doesn't come from them - the source
| address is whoever actually sent the traffic. And the
| destination address is you, but the Internet thinks they
| are hosting you. They can't just forward the same packets
| to you because they'd just go back to the DDoS provider
| because that's where "you" "are". So they put the packets
| inside other packets and send them to you on a different
| address.
|
| I suppose they could rewrite the destination to be your
| real address, and then send them to you without extra
| layers; you wouldn't get to know what the original
| destination address was; maybe if you only have one, it
| doesn't matter.
| VladVladikoff wrote:
| Most websites don't need DDOS protection. Many websites which
| use Cloudflare to block basic bot vulnerability scanning. You
| could block this type of traffic with other methods; ja3/ja4,
| Ip to ASN & ASN filtering, etc.
| esseph wrote:
| Your first line is wrong.
|
| While it may not impact your site, it does impact your
| hosting provider. As their costs go up, your costs go up.
| Anything on the Internet at this point needs DDoS / scraping
| protection. If may not drop your service, but your ISP or
| upstreams may blackhole your route.
|
| The "old web" (current web) was largely based on an open
| exchange of information.
|
| The "new web", post AI bot scraping, is taking its place.
| Websites are getting paywalls. Advertising revenue is
| plummeting. Hosting providers are getting decimated by the
| massive shift in bandwidth demand and impact to systems
| scraped by the bots.
| VladVladikoff wrote:
| I guess my products fall into a niche that doesn't seem to
| attract AI crawlers. I've seen only a few and they haven't
| been too aggressive. I mean they ignore typical crawl rate
| limits defined in robots.txt but account for maybe only
| 1-2% of my overall traffic.
| immibis wrote:
| DDoS and AI are mostly unrelated. Sure, AI companies are
| running low-quality scrapers, but they don't cause nearly
| as much traffic as a DDoS. They might cause as much CPU
| load as a DDoS, which is an application-level problem.
| zzzeek wrote:
| dont piss off any nation-states that would want to take your
| site down, should help
| petee wrote:
| Fwiw, i have a site with nearly zero content or users;
| randomly it got ddos'd one day, and never happened again. I
| think the reasons for a ddos can be wide ranging, from just
| testing, to nation state, to someone is unhappy with your
| font choice
| inetknght wrote:
| > _to someone is unhappy with your font choice_
|
| _Everyone_ hates when I set my app 's fonts to courier
| size 8.
| esseph wrote:
| An 11 year old with a discord account and a stolen credit
| card can now rent massive capabilities that can take
| (smaller, limited peered) entire countries offline for brief
| periods these days.
| immibis wrote:
| The simplest is to just wait until the attacker is bored,
| and/or daddy's credit card runs out.
|
| If you aren't doing any business, or not much business, through
| your site, this can be fine. Your hosting provider may either
| choose to let your server be overwhelmed with as many packets
| as its pipe can fit, or it may need to protect its network by
| discarding traffic to your IP address upstream of itself. It's
| probably a good idea to reach out to your hosting provider and
| let them know you're getting DDoSed. Even if they can't do
| anything about it (though there's a chance they can) they'll
| hopefully appreciate the heads up.
|
| True story: I ran a Pixelflut client for 38C3 from a Netcup
| server in Nuremberg (this somehow had better performance than
| running it on my tablet _at the physical location_ ) and they
| somehow thought 38C3 was DDoSing me and "helpfully" blackholed
| traffic between 38C3 and my server.
|
| ---
|
| It's important to stop thinking of DDoS as some magic hammer of
| Thor that you can't do anything about. DDoS packets, like all
| other packets, have source and destination addresses and flow
| through routers and links.
|
| When Cloudflare receives a 7-terabit DDoS, they aren't
| receiving 7 terabits through one link. Cloudflare operates a
| huge number of locations that pretend to be one coherent
| network. So they're receiving 100 gigabits in London, 100
| gigabits in Frankfurt, 200 gigabits in NYC, etc. Their network
| architecture pretends like it's delivering all these packets to
| their destination addresses, but really, each location has its
| own completely different set of servers that all have the same
| addresses. (This is called anycast.) Each individual packet
| sender is only sending packets to the nearest Cloudflare node,
| where they're getting discarded. Likely, no individual node is
| overloaded by this, but when you aggregate the statistics from
| all of them, it adds up to a large amount of traffic. This is
| by the nature of a DDoS - it's devices all over the world
| attacking you, which means they're all coming by different
| routes.
|
| It's similar with hosting providers too, at least the big ones.
| Suppose you're on Hetzner:
| https://www.hetzner.com/unternehmen/rechenzentrum/ . They're
| not getting a terabit against your server through one link -
| they're getting 100Gbps through DE-CIX Frankfurt, 10Gbps
| through AMS-IX, 50Gbps through Telia in Nuremburg, 50Gbps
| through Telia in Helsinki, 50Gbps through Core-Backbone, etc.
|
| If they deploy a routing rule to the router on their end of
| each of those links, which says to discard packets where the
| destination address is yours, they can protect their network.
| Your site will still be down, of course.
|
| If one of their pipes does get overloaded (say their full
| 10Gbps from Baltnet in Frankfurt), they can reach out to that
| network (pretty much every serious network on the internet has
| a network operations center, reachable 24/7 by phone) and
| Baltnet will track it down further and block the traffic even
| closer to its source (or at a wider part of their network).
|
| If you're lucky and the DDoS traffic is just coming from a few
| "directions", users whose packets happen to come via a
| different direction may still be able to access your site.
|
| Suppose you're on Uncle Tom's Tiny Hosting Company Ltd (not
| real), they're certainly not the scale of Hetzner, and they
| only have a 10Gbps pipe between them and their ISP which is
| easily filled by a single attack. They'll have to contact their
| ISP to block traffic to your server so that the rest can get
| through, and their ISP will do the above stuff.
|
| None of this information will keep your site up during a DDoS,
| I just want to show you there's a depth to this DDoS thing and
| this Internet thing and it's not just magic.
| encom wrote:
| So this "article" "source" is Cloudflare, claiming Cloudflare
| blocked some super duper mega attack, but gives zero verifiable
| detail about any of it.
|
| Now I hate Cloudflare with a passion, but even setting that
| aside, this is journalistic malpractice - it's basically a
| sponsored post. I was going to say I expected better from Ars
| Technica, but their glory days are long gone.
| gundmc wrote:
| Why do you hate Cloudflare so passionately?
| immibis wrote:
| There are many reasons Cloudflare should be hated. The main
| one is that their goal is to centralize the Internet. A
| secondary one is all those bloody captchas. A tertiary one is
| that they often block Tor, even if you pass a captcha. Yes,
| it's configurable, but their recommended settings are the
| ones that help break the internet.
|
| However in this case I think we can rely on them to tell us
| what they did. If they say they got a 7.3 Tbps UDP DDoS,
| chances are good they actually did.
| greggsy wrote:
| How is CF not a valid primary source?
|
| They literally are a DDoS mitigation service.
| esafak wrote:
| Who's doing this and why?
| ChrisArchitect wrote:
| [dupe] discussion on source:
| https://news.ycombinator.com/item?id=44330585
___________________________________________________________________
(page generated 2025-06-21 23:01 UTC)