when cloudflare is down:
"haha losers that's what you get for using a centralized MitM-as-a-service"
when getting DDoSed:
"help! cloudflare pls save me from the bad guys"
when cloudflare is down:
"haha losers that's what you get for using a centralized MitM-as-a-service"
when getting DDoSed:
"help! cloudflare pls save me from the bad guys"
(btw. the person I'm mocking is me)
@wolf480pl Does DNS not have a "try this IP first, then this one if the first one is down" feature?
@sjb kinda sorta not really
@sjb ok supposedly it works with modern browsers https://webmasters.stackexchange.com/questions/10927/using-multiple-a-records-for-my-domain-do-web-browsers-ever-try-more-than-one
@sjb well the DNS record needs to point somewhere...
btw. yes this happened, at previous job we got hit with an application-level DDoS of low bandwidth and around 1000 req/s which was 100x more than normal traffic and overwhelmed our shitty Django webapp.
Banning IPs / rate limiting didn't help because they kept coming with new ones. I'd somehow need to know the list of IPs ahead of time.
Caching would probably work until they figured out that the session cookie (ppl can log in) must be part of the cache key.
1/
I could've found an out-of-spec header they're sending and block based on that, and it would've worked until they figured that out too.
I could've made my own captcha / proof-of-work authentication thing, that'd probably work (unless the bot can run JS).
Or I could use CloudFlare which appears to do all of the above for me, with economies of scale, and experience greater than I have.
Or I could've accepted the downtime.
What would y'all have done?
2/2
@wolf480pl
--[What would y'all have done?]--
Same thing I always do. Use the cloud thing as the *fallback* not the primary.
Chirp! is a social network. It runs on GNU social, version 2.0.1-beta0, available under the GNU Affero General Public License.
All Chirp! content and data are available under the Creative Commons Attribution 3.0 license.