 You might have guessed it already: We are struggling with excessive crawling today. We have - again - blocked several large IP ranges, but were not yet able to identify the new actor. We are working on restoring service availability and fine-tuning our rate-limiting. If someone is interested in implementing an improved native rate-limiting in #Forgejo that also protects other instances from abusive crawlers, please reach out 😉 14 comments
@fmartingr We're using haproxy and have a custom blacklist loaded here: https://codeberg.org/Codeberg-Infrastructure/scripted-configuration/src/commit/bef038ca91cb928e0b865ada4bc6d579b2bc857e/hosts/kampenwand/etc/haproxy/haproxy.cfg#L265 It's not public (yet), but we should probably consider opening it. Would need a check there are only publicly known IP addresses on there, though. I'm not fully up to date with how law considers publishing IP ranges of bad actors. ~f @Codeberg I was considering trying something like CrowdSec, but unsure how they handle the bad IP ranges and what they consider "bad actors". If we could had something like that but with lists like adblockers do, maintained by the community, it could be nice. Will take a look :blobfoxeyes: Thanks and hope you resolve the issue soon! Does "Aceville" ring bells for anyone by chance? Related to tencent probably? We are blocking one IP range after another ... @Codeberg I won’t be able to provide an implementation but for better understanding: How does rate limiting work now and what kind of improvement would be helpful in your current scenario? @dboehmer One of the primary constraints of the current rate-limiting is that there is only a global counter that increases for each request. So a user watching Forgejo Actions logs scroll through will fire a lot of small requests. And a botnet that is distributed over many many IP addresses do not trigger the rate-limiting at all, because each server only fires a few requests.  @Codeberg as an emergency measure I'd prbly block non-authenticated http (except signup + login) altogether.  @Codeberg Any chance you put some honeypot paths in robots.txt that trigger fail2ban against any requestors? @Codeberg @grote We have blocked several offending IP ranges. Is there information about which hosting providers Fdroid uses? @Codeberg @grote @fdroidorg where are production buildservers are located is not public information, and it is not necessarily static. But I imagine it would be easy to figure out which IP address by looking at the logs on the codeberg side. We haven't been blocked before by any other git/scm hoster, to my knowledge. |
Gregory's Server
@Codeberg We block all Azure now. Users whine but if they want good service they shouldn't be using an address in the bad part of Internet Town.