So @lwn is currently under the heaviest scraper attack seen yet. It is a DDOS attack involving tens of thousands of addresses, and that is affecting the responsiveness of the site, unfortunately.

There are many things I would like to do with my time. Defending LWN from AI shitheads is rather far from the top of that list. I *really* don't want to put obstacles between LWN and its readers, but it may come to that.

(Another grumpy day, sorry)

@corbet @lwn
As a avid longtime subscriber and reader, I can only give thanks and hope you will survive also this blast of willfully wrong behaviour. Thank you for your openness.

@corbet @lwn Been there. ;( #hugops

@corbet @lwn Any inkling which AI (Arsehole Incorporated) it is? The crash can't come soon enough.

@foxylad @lwn There is no way to know who is after the data. The actual attack is likely perpetrated by Bright Data or one of its equally vile competitors.

@corbet @lwn
Just speaking with my user hat on here, but given the circumstances I don't mind the ever-so-slight inconvenience of an #anubus challenge.

@corbet @lwn If you need help, email me. I can work with you in case there's low hanging fruit that you missed.

@corbet @lwn

This helped me a lot with my little projects:
https://codeberg.org/skewray/htaccess

@corbet @lwn Obviously that sucks, but I am super happy with the RSS integration that I get with my lwn subscription. People who are affected by the outage should check that out. Not really a solution, but maybe part of one.

@corbet @lwn I'm not sure how people in the kernel community reconcile using LLMs with the effect these LLMs have on small businesses and individuals hosting their websites for fun and it's not as if the kernel community itself isn't affected by these incessant DDoS attacks.

@corbet @lwn 100% PURE BAISAIRDS!

@cadey @corbet @lwn
I recently saw a traffic spike to a small HTML-only website that never had WP on it, but was suddenly getting failed wp-admin logins and hundreds of PHP vuln scans, non stop. All from MSFT IP addresses. Abuse reports were sent, but there was no response, and the abuse kept happening.
So now I'm blocking every MSFT CIDR block that I can find, server-wide.

@corbet @lwn I've been experiencing about 20x more website traffic than normal, myself. It's very likely this scraper bot traffic as well. Things are holding, but only because I took pains to use static site generation (absolutely minimal Javascript, designed to be lightweight).

@suihkulokki @lwn The problem with that solution is that it may well make it harder for us to bring in new subscribers, which is something we definitely want to do. First impressions matter, so giving new folks a poor experience seems ... not great.

It may yet come to that, though.

@jani @lwn @suihkulokki Such things have crossed our minds, certainly. The gotcha there is that we've already had troubles with bots creating accounts; I don't think they would hesitate to do more of that if that would improve their access.

That and, of course, the fact that everybody starts as an unregistered user. As long as we can avoid making the experience worse for them, I think we should.

@jani @lwn @suihkulokki Suggestions are much appreciated! It's not as if we've figured all this stuff out...

@corbet @lwn @jani @suihkulokki I have a simple solution: Stop being so damn relevant!!!

Wait... 🤡

@jani @corbet @lwn @suihkulokki Sorry, I was being too optimistic... I was thinking they wanted sources with high SNR... But you are probably right...

@corbet @lwn @jani @suihkulokki one day the photocopiers will get busy after the office hours again, but this time it's going to be linux weekly news instead of the punk fanzines

@corbet @lwn iocaine?

@corbet @lwn @jani @suihkulokki for RationalWiki I've had to resort to a mandatory JavaScript trick that sets a cookie. Unfortunately it seems to block Googlebot, but it's down to (a) human users can use the site (b) nobody can use the site including Googlebot.

@dec23k @cadey @corbet @lwn I have a tiny site. SSH moved to a different port.
I see hundreds of locing attempts a day. I receive a summary via logwatch. Nearly every day I'm blocking whole /24 or even /16.

I rely on fail2ban to mitigate suche Webserver DDOS, but maybe thats not enough.
How do you detect those spikes?

@dec23k @cadey @corbet @lwn Some days, the answer is to hit a BGP looking glass and just block every prefix from the origin AS of that service provider.

@corbet Instead of making it worse for unregistered users, how about sharding the site with recent frequently accessed content separate from old long-tail? Easier to keep a small site in cache.

@trademark Making things worse for real users is something we have gone far out of our way to avoid. I'm not sure that sharding in that way would help much, though; cache isn't really the problem.

@corbet Can you say what the problem is? CPU, contention in unshardeable database?

@trademark CPU primarily when things get really crazy. More CPU is easily arranged, of course, but it is irritating as hell to have to pay for that to feed our hard-written articles to those people.

@corbet Yeah, you're running python code? Other option is to try a JIT or Cython, but if you value your time it might be more expensive to debug that than to pay for the extra CPU :(

@dec23k @cadey @corbet @lwn @davidgerard we have a program that hooks into nginx on one end and freebsd blocklistd on the other and when someone hits up PHP endpoints on our sites that havent had PHP on them in over 20 years, they get firewalled. sure as shit, most of them come from azure. also we host our own email and most of the spam that makes it through our filters comes from google. makes u think dot jpeg

@atax1a @dec23k @cadey @corbet @lwn my hazard keeps being Ali and particularly their Singapore region, which I gave an automatic 503 to the whole /16 for

@dec23k @cadey @corbet @lwn grebedoc.dev gets these on a hourly basis (I solve it by just serving the 404s, it's not a problem for my server software)