Database abnormally increases from 130 to 1400 MB

[Sono]

And how can you block IP range in that? I found tutorials online but those listed a solution like banning 1.1.1.* But what if you just want to ban a specific section of that range like 1.1.1.2 - 1.1.1.10 ? To that one I did not find a solution.

IP Range To CIDR
https://www.ipaddressguide.com/cidr

Thanks!

[Dblog]

If you observe the urls hit by those bots, almost all of them have different PHPSESSID=xxx appended in the end.
It is this session id in SMF, exploited by bots.
Isn't it time to get rid of it ?
even pretty urls have PHPSESSID appended at first guest view

[Arantor]

It's not that they're being "exploited", because that's not what the PHPSESSID is for.

The idea is that if they don't have cookies, track their session via URL so that you can have a more accurate number of "users online at once".

Bots that don't bother presenting cookies (because bad bots) should be blocked before even getting to SMF.

But in principle I agree with removing the SID injection, though not because it's "an exploit". It has definitely outgrown its use.

[Dblog]

Bots that don't bother presenting cookies (because bad bots) should be blocked before even getting to SMF.

How to achieve that ? There are few complicated mods but they increase database size and add extra files.
SMF needs a method to block a bot at first visit if they dont follow rules

[Arantor]

No, that's not an SMF level problem. That's something you do at the server level - because it consumes vastly less server effort to block bad bots in the htaccess file rules than it does to wait until it gets to SMF to block.

[Sono]

No, that's not an SMF level problem. That's something you do at the server level - because it consumes vastly less server effort to block bad bots in the htaccess file rules than it does to wait until it gets to SMF to block.

Any directions for that? The code I used doesn't deter all away. Still 11GB per day. According to latest measurements. How can you do that cookie presenting check?

[Arantor]

Given that I have no idea what code you used, it's impossible to say. The usual approach is just to stack up lists of blocks by user agent and/or misbehaving IP address ranges, especially because it really depends who's visiting *you* that shouldn't be.

But the cookie presenting check is LITERALLY NOT RELATED. First time *I* come to your site, I don't have cookies to present either, because I don't get cookies *until I've been to your site*. So you can't use that as criteria to deter anyone. (And nor should you.)

[Dblog]

They'll come with new IPs.

Pattern i observed is : same IP is used to visit multiple urls, all with PHPSESSID=xxx appended.
Your first visit needs it. But why use different PHPSESSID repeatedly within few minutes from same IP.
This pattern needs to be blocked and i couldnt find any tool in admin

[Arantor]

But why use different PHPSESSID repeatedly within few minutes from same IP.

Because they're not bothering to collect and send the cookies back (as they should)

This pattern needs to be blocked and i couldnt find any tool in admin

No.

Identify the bad bots either by IP address or user-agent (you have logs, use them) and block them in htaccess because that can do it saving so much more bandwidth than SMF can possibly under literally any circumstances.

The exact details depend on your hosting setup which I can't possibly tell you, because I'm not a mind reader. But assuming you're using an Apache based hosting with .htaccess, there's any number of lists out there of bots to block.

[Kindred]

DBlog-

Stop
You think you know more than you do and you are wrong.

[Sono]

Given that I have no idea what code you used, it's impossible to say. The usual approach is just to stack up lists of blocks by user agent and/or misbehaving IP address ranges, especially because it really depends who's visiting *you* that shouldn't be.

But the cookie presenting check is LITERALLY NOT RELATED. First time *I* come to your site, I don't have cookies to present either, because I don't get cookies *until I've been to your site*. So you can't use that as criteria to deter anyone. (And nor should you.)

The problem is that I block a range, and in 5 minutes the bot comes back from another one. There was 5 yesterday that I banned and all came back by now from a different location. It is a cat and mouse game this way.

Also the anti-bot code that I pasted above in a post does not work by now. A few months ago it worked, but now, it was effective for one day. The daily bandwidth fell to 1GB per day, but in 2 days it climbed back to 70GB. These bots know you want to trick them and come back the other way.

[Arantor]

I mean, if your issue is bots from Amazon, block ALL of Amazon. Amazon publishes its IP ranges - https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html

If you're blocking by user agent that list should just be growing, not shrinking over time.

[Sono]

I mean, if your issue is bots from Amazon, block ALL of Amazon. Amazon publishes its IP ranges - https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html

If you're blocking by user agent that list should just be growing, not shrinking over time.

It is not just Amazon. Worldwide. Lots of countries. Incl. Western Europe, not just suspicious third world locations. Moreover I banned some ips, and today when I checked the log, the redirect from the banned ip is there again. In spite of that the ip is banned in htaccess. I don't understand how it is possible?

[Arantor]

Amazon is worldwide though... including in the multiple data centres in Western Europe.

Look, I don't know what you've actually done. I don't trust that you have actually done what you think you may have done, and that you probably should be discussing this with your host as it is in their interest that this be resolved.

[Sesquipedalian]

you probably should be discussing this with your host as it is in their interest that this be resolved.

This is correct. If there are no more errors appearing in the SMF error log, @Sono, then you have fixed your SMF-related problems. If your hosting provider limits the amount of bandwidth your website can use, then you need to talk to your host about ways to block excessive requests—or even better, consider moving to a host that doesn't limit your bandwidth.

[Sono]

you probably should be discussing this with your host as it is in their interest that this be resolved.

This is correct. If there are no more errors appearing in the SMF error log, @Sono, then you have fixed your SMF-related problems. If your hosting provider limits the amount of bandwidth your website can use, then you need to talk to your host about ways to block excessive requests—or even better, consider moving to a host that doesn't limit your bandwidth.

The error log in the database has been empty since I deinstalled Optimus, and added that anti bot code I mentioned. Thank you very much for the advice! I just have not mentioned it yet because I am still monitoring the activity in the log, but so far it seems what you suggested was the solution. Let us hope it will stay like that.

I am just asking the other things because I am not sure the host will care about it, and I am still afraid to ask them, because I fear if they notice the daily bandwidth usage is 70GB they will ban me right away. It is not a limited hosting, but even so 1TB per 12 days seems a reason for ban to me.

Anyway let me just ask about these, because these are really odd. How is this possible for example? A new redirect attempt today, and when I check the ip it says this is the Google bot. Now should I ban this bot or not, considering this is related to Google?

The log:

Code Select Expand

66.249.70.7 - - [03/Feb/2024:18:17:26 -0800] "GET /index.php?thememode=full;redirect=https://vrs.com.ua/vfwchgormslw HTTP/1.1" 403 1485 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.85 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

The IP info:


And another thing: what is this ?thememode=full tag? Every redirection request want to use that tag (/index.php?thememode=full) but it seems to make no sense for me when comparing to /index.php simply. Isn't is possible to ban that tag and thus putting an end to these redirect requests?

[Kindred]

Looks like a stupid script kiddie because that's a WordPress hack


But your server is already returning a 403

[Sono]

Looks like a stupid script kiddie because that's a WordPress hack


But your server is already returning a 403

What do you mean by that? The script running on the hosting account itself that want to redirect?

You spotted correctly it is returning an error. I did not notice I already banned that range earlier. But this is what I referred to a few posts above: the banning is there in the .htaccess, yet the activity of the bot is still logged. How is that possible? This is from today:

Code Select Expand

66.249.69.192 - - [04/Feb/2024:05:53:26 -0800] "GET /index.php?thememode=full;redirect=https://katrusinkinozal.com.ua/phwpwikgxsjk HTTP/1.1" 403 1485 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.6167.85 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

The ban is there in .htaccess:

Code Select Expand

Deny from 66.249.64.0/19
According to the lookup, that is the CIDR for that range: 66.249.64.0 - 66.249.95.255

It says this is Google's server. 

[Kindred]

What do you think a deny does?  The attempted link returns a 403, that's appropriate.
...

A script kiddie is a lazy hacker who sends out queries for all known hacks,  whether or not you're running the software.
But these attempts are not going to pile on your bandwidth.

[Arantor]

Indeed, the response to that bot request was 1485 bytes of error message.