Last year, I read your post and implemented it. I had no way to tell whether there is any benefit to it, so I discontinued it. Serving the data, even though it is compressed and the compression is precomputed, was still a waste of bandwidth. It could hit the browsers of legit user (false positive).
replyThe main problem on my site is that bots hit the CGIT repo, where visiting files triggers syntax highlighting scripts.
I put in a skill-testing-question type system where you get a maximally long-lived access cookie if you answer right (so legit users are bothered as infrequently as possible).
So it ended up not having a noticeable impact on the bots?
replyIt worked fine... on a small scale But it's one thing to swat flies versus fighting swarm of yellow jackets. Serving a 1MB file a million times a day on a small digitalocean droplet is not feasible. Let's just say it didn't scale. And AI bots usually come with beefier machines, and recover faster after a bomb.
replyWhy did you serve it from DigitalOcean?
replyWhy not a CDN?
It's the content of the page, the raw html, that is replaced with a zipbomb. Example: https://example.com checks if you are a malicious bot, depending on the result, it will send you gzip html or gzipped bomb. So that can't be swapped or redirected to a CDN. The bots would simply ignore the redirect.
replyThat sounds really annoying. Thanks for explaining! I'm looking to launch one of my new little products and my last one got hammered by bots.
replyThankfully they were not really malicious like some of the other folks have experienced, but it was still frustrating.
Can that technique be applied to packet compression?
replyWhat is that improved strategy? :pray:
replyNot telling you this time, Mr. Bot
reply