Crazy amount of guests

[BrettC]

Damn, you had to ban linux users huh



If they are using real browsers, then yes, they can get around almost anything. The more people who use anubis, the higher the cpu tax will be on these bot farms and we could theoretically make the job too expensive if tons of people use something like anubis, so it's a good thing your site is making them pay the tax. I think the only way it could work is that everyone has to pay the tax, though.

We may join you in helping deliver 1 of the 1000 tiny cuts needed soon.

View attachment 334014

I notice they are getting more clever and more distributed too.
The number of guests on my site no longer affects volume less and frequency of rotation more.
I have yet to go in there and look for more subnets to ban. I'm thinking of writing something that automatically bans those..

I wouldn't say that I've banned Linux users, but filtering out HeadlessChrome UAs. That's a version of chrome that has absolutely no GUI. Which generally translates to a bot/scraper.

Unfortunately, todays event wasn't a good sign to see. Primarily due to how Anubis was being solved for some clients on a challenge level of 5. Going higher in these levels tends to become problematic for legitimate users. Guess I can make much more surgical challenge levels to certain clients matching certain browser criteria. Upping challenge levels to those CIDR blocks aren't an ideal method any more when it comes to Residential Proxies getting used.

Ugh... just ugh.

 

[ES Dev Team]

I don't expect any UA identification to work in the future. The majority of bots i see are randomizing theirs.

The way i would configure anubis:

• users submit 5 seconds of CPU time
• we retain the 'user passed the check' for 30 days so a real user only needs to pass it rarely
• rework the anubis UI to resemble a welcome screen so it's more friendly

You can't differentiate between logged in users and not on a webserver level, but if you could, you could have one standard for guests and a super lax one for people who are logged in.

I think this involves the custom software i've been thinking about.

 

[chillibear]

You can't differentiate between logged in users and not on a webserver level, but if you could, you could have one standard for guests and a super lax one for people who are logged in.

Well you could check for the login cookie. Granted you'd not be validating its contents, but the lack of one certainly indicates a guest, even if the presence of one doesn't 100% mean logged in valid member. I tend to do that in our (nginx) logs so I can idly grep out member or guest traffic depending on what I want when I'm watching it.