TechTakes

1511 readers

190 users here now

Big brain tech dude got yet another clueless take over at HackerNews etc? Here's the place to vent. Orange site, VC foolishness, all welcome.

This is not debate club. Unless it’s amusing debate.

For actually-good tech, you want our NotAwfulTech community

founded 2 years ago

MODERATORS

[email protected]

LLM training bots are a plague (pod.geraspora.de)

submitted 1 week ago by [email protected] to c/[email protected]

14 comments fedilink hide all child comments

Evidence for the DDoS attack that bigtech LLM scrapers actually are.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 6 points 1 week ago (1 children)

I used to get a lot of scrappers hitting my Lemmy instance, most of them using a bunch of IP ranges, some of them masquerading their user agents as a regular browser.

What's been working for me is using a custom nginx log format with a custom fail2ban filter that mets me easily block new bots once I identify some kind of signature.

For instance, one of these scrappers almost always sends requests that are around 250 bytes long, using the user agent of a legitimate browser that always sends requests that are 300 bytes or larger. I can then add a fail2ban jail that triggers on seeing this specific user agent with the wrong request size.

On top of this, I wrote a simple script that monitors my fail2ban logs and writes CIDR ranges that appear too often (the threshold is proportional to 1.5^(32-subnet_mask)). This file is then parsed by fail2ban to block whole ranges. There are some specific details I omitted regarding bantime and findtime, that ensure that a small malicious range will not be able to trick me into blocking a larger one. This has worked flawlessly to block "hostile" ranges with apparently 0 false positives for nearly a year

[–] [email protected] 6 points 1 week ago (1 children)

the threshold is proportional to 1.5^(32-subnet_mask)

what are you basing that prefix length decision off? whois/NIC allocation data?

is the decision loop running locally to any given f2b instance, or do you aggregate for processing then distribute blocklist?

either way, seems like an interesting approach for catching the type of shit that likes to snowshoe from random cloud providers while lying in agent signature

[–] [email protected] 2 points 1 week ago (1 children)

CIDR ranges (a.b.c.d/subnet_mask) contain 2^(32-subnet_mask) IP addresses. The 1.5 I'm using controls the filter's sensitivity and can be tuned to anything between 1 and 2

Using 1 or smaller would mean that the filter gets triggered earlier for larger ranges (we want to avoid this so that a single IP can't trick you into banning a /16)

Using 2 or more would mean you tolerate more fail/IP for larger ranges, making you ban all smaller subranges before the filter gets a chance to trigger on a larger range.

This is running locally to a single f2b instance, but should work pretty much the same with aggregated logs from multiple instances

[–] [email protected] 2 points 1 week ago

I'm aware of the construction of a CIDR prefix, I meant what are you using to categorise IPs from requests to look up mask size? whois? using published NIC/RIR data? what's in BGP/routedumps? other?