Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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


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.


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 ;)


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: