[mst]

Internet security has, in my experience, always been about "being just hard enough a target the bad actors decide to go torment somebody else."

It was true twenty years ago too, the only difference I can see between then and now is that you can outsource that task for a (relatively) small amount of money if you want to.

Then again, the last time I dealt with a site under DDoS, something in their stack was leaking the underlying IP (never did figure out what) but it turned out that "finding a provider who'd sell them a decent sized server and charge them for the bandwidth" was perfectly economical for their use case because their haters' firepower was insufficient compared to their revenue.

(I'd love to be less vague here but I'm sure readers can see the obvious professional ethics issues with doing so)

[WirelessGigabit]

I'm surprised you're handing incoming requests from everybody. We only process the CloudFlare ones and drop the rest.

[lillecarl]

You can fill the pipes to the server(s) you're targeting, it doesn't have to be application layer.

[yencabulator]

These days, Cloudflare lets you serve your origin via a tunnel from a host that doesn't even have a public IP.

And if you run that in a cloud, the NAT isn't your problem -> your attacker will have to DoS that cloud as a whole.

[mst]

That's an extremely smart approach that I sincerely doubt the site operators would have been capable of dealing with.

Part of the art of consultancy is, sometimes to my great annoyance, optimising for "within the customer's budget" and "within the customer's capacity to maintain it after I'm no longer involved" over "best possible solution."

Plus in this particular case I was working pro bono because (a) I quite liked the site in question continuing to exist (b) a Shadowcat alumnus asked me nicely (c) I take great pleasure in ruining a griefer's entire week. So lightest possible touch was strongly indicated.

The end result was not remotely clever, but it's been in production for a while now and has not to my knowledge caused financial or uptime issues, so I'm going to call it a win even if the inelegance of -how- I won continues to irritate me ;)

[mst]

Right, "finding a provider whose reaction to an aggravating quantity of incoming packets was charging money rather than throttling the connection" was basically the load bearing part of the solution here.

Fortunately, while said quantity was indeed aggravating, it was low enough that the cost was financially and logistically less than trying to do something more elegant.

Sometimes brute force and ignorance is, in fact, the right answer, and I don't have to -like- that being true for it to be true.