AbuseIPDB Integration module

[HeathenMagic]

To fix the issue:

First, uninstall the current AbuseIPDB plugin.

Then re-download the latest ZIP for v4.0.8 — the fix is included now. (I had missed a section)

The new installer will automatically create the correct tables using your database prefix.

You can safely delete the old tables (the ones without the prefix), as they are no longer used if they are still there.

Thats great! I can confirm it is all working perfectly. I have enabled most of the settings that I understand, octet, flood, and session rate limiting. I think the module doesn't automatically block the IP, I refer to whos online and add to the blacklist text file? I have started doing that, and enabled the blacklist execution anyway.

[marcopolo]

Thats great! I can confirm it is all working perfectly. I have enabled most of the settings that I understand, octet, flood, and session rate limiting. I think the module doesn't automatically block the IP, I refer to whos online and add to the blacklist text file? I have started doing that, and enabled the blacklist execution anyway.

Great to hear it’s working now!

The module does automatically block IPs when their AbuseIPDB confidence score exceeds the threshold you’ve configured — no need to manually blacklist them. That part is handled in real time.

As for the features you enabled:

Octet blocking looks for too many hits from the same IP range (e.g. 123.45.67.*) and can block the entire subnet if abuse is detected.

Flood control has multiple layers — depending on which option is enabled, it can detect surges from foreign countries or large volume from specific subnets.

Session rate limiting watches for how quickly new sessions are created and blocks IPs exceeding the limit.

Each setting has its own logic and threshold — and the README walks through all of them in detail. Give it a look when you can.

[HeathenMagic]

Great to hear it’s working now!

The module does automatically block IPs when their AbuseIPDB confidence score exceeds the threshold you’ve configured — no need to manually blacklist them. That part is handled in real time.

As for the features you enabled:

Octet blocking looks for too many hits from the same IP range (e.g. 123.45.67.*) and can block the entire subnet if abuse is detected.

Flood control has multiple layers — depending on which option is enabled, it can detect surges from foreign countries or large volume from specific subnets.

Session rate limiting watches for how quickly new sessions are created and blocks IPs exceeding the limit.

Each setting has its own logic and threshold — and the README walks through all of them in detail. Give it a look when you can.

Thanks a lot for that! And for the concise point on its features. I have referred to the readme previously, I overlooked the point that I can lower threshold to auto-block. I think I will lower to 40 instead of 50, that might cut a lot more bad bots out. Great module once again!

[HeathenMagic]

Think they must have targetted me this morning as seems 5000 request daily limit already reached! I reckon the previous blocked is tied to Abuse account so it can't retrospectively block those again. I only added one ip to that blacklist file (on top htaccess rules and IP blocked ranges on server).

[marcopolo]

Think they must have targetted me this morning as seems 5000 request daily limit already reached! I reckon the previous blocked is tied to Abuse account so it can't retrospectively block those again. I only added one ip to that blacklist file (on top htaccess rules and IP blocked ranges on server).

Yes, it can block those same IPs again — but only if they return after their cache entry expires. By default, the plugin caches each IP’s AbuseIPDB score for 1 day (86400 seconds) under the Cache Time setting. That means once an IP is checked, its score is stored locally and reused until that cache expires — avoiding repeat API calls, but also meaning the system won’t recheck or re-block the same IP until that cache period ends.

If you're seeing a spike in abuse, you can temporarily increase the cache time (to 2–3 days, for example).
172800 = 2 days or 259200 = 3 days

That way:

• Previously flagged IPs stay blocked longer, even without another API call
• You conserve your daily quota (5,000 requests) during surges
• Protection stays active while usage stays within limits

Also, enabling extended caching (High Score Cache Extension) for IPs over a threshold (default score: 100) can stretch cache time even further (defaults to 7 days or longer whatever you set it too via Extended Cache Time).

I’ve seen a huge uptick in bot traffic lately, especially from IPs returning very low or even 0 scores from AbuseIPDB. Something definitely seems to be going on across multiple shops. You’re not the only one running into this pattern.

[HeathenMagic]

Yes, it can block those same IPs again — but only if they return after their cache entry expires. By default, the plugin caches each IP’s AbuseIPDB score for 1 day (86400 seconds) under the Cache Time setting. That means once an IP is checked, its score is stored locally and reused until that cache expires — avoiding repeat API calls, but also meaning the system won’t recheck or re-block the same IP until that cache period ends.

If you're seeing a spike in abuse, you can temporarily increase the cache time (to 2–3 days, for example).
172800 = 2 days or 259200 = 3 days

That way:

• Previously flagged IPs stay blocked longer, even without another API call
• You conserve your daily quota (5,000 requests) during surges
• Protection stays active while usage stays within limits

Also, enabling extended caching (High Score Cache Extension) for IPs over a threshold (default score: 100) can stretch cache time even further (defaults to 7 days or longer whatever you set it too via Extended Cache Time).

I’ve seen a huge uptick in bot traffic lately, especially from IPs returning very low or even 0 scores from AbuseIPDB. Something definitely seems to be going on across multiple shops. You’re not the only one running into this pattern.

Thanks for your reply, and I have took action on one of your tips so far. Just looking into the other one. Apparently I had 60000 connections in two hours! Which tallies with the logs around that duration. I'd turned off session rate limiting so turned it back on again. Was investigating a session related bug.
So its not just me then....... I know another business they block Sinagpore and China, as recommended by their server people. But the former can have customers from there. Yes its definitely not something I have had to tackle this viciously before.

[HeathenMagic]

Server is offering to do blanket ban on subnet, but the excerpt they showed me, some are google and microsoft bots. They check out genuine, in similar range. Perhaps the rest of excerpt are the bad ones. Another few were another search engine bot. Seems strange...... I will see what other ip address ranges they found, don't want to block the good ones.

[HeathenMagic]

I just wondered, I am doing the country ban using the setting in Abuseipdb. If I do that at .htaccess / server level, that would reduce lookups and stop daily exhaustion of 5000 allocated lookups I think? I am getting about 8 countries I never send to, with repeated spam bots that are showing up as bad bots on the tools I use.

[marcopolo]

I just wondered, I am doing the country ban using the setting in Abuseipdb. If I do that at .htaccess / server level, that would reduce lookups and stop daily exhaustion of 5000 allocated lookups I think? I am getting about 8 countries I never send to, with repeated spam bots that are showing up as bad bots on the tools I use.

That kind of blocking is outside this module not sure how that would be done exactly in .htaccess.

When you say country ban remember there tare two one is "Enable Country Flood Detection?" I wouldn't recommend using that one unless you really have to, since it can block IPs from within your own country (which is set in the module settings).

Instead, you can use "Enable Foreign Flood Detection?", which specifically targets traffic from outside your default country and is much safer in most cases.

Also worth noting — AbuseIPDB does offer paid tiers that increase your daily API limit. The first paid tier bumps you up to 10,000 lookups per day, and I believe the next one is 50,000 — you’ll want to check their pricing page for the latest details.

[HeathenMagic]

That kind of blocking is outside this module not sure how that would be done exactly in .htaccess.

When you say country ban remember there tare two one is "Enable Country Flood Detection?" I wouldn't recommend using that one unless you really have to, since it can block IPs from within your own country (which is set in the module settings).

Instead, you can use "Enable Foreign Flood Detection?", which specifically targets traffic from outside your default country and is much safer in most cases.

Also worth noting — AbuseIPDB does offer paid tiers that increase your daily API limit. The first paid tier bumps you up to 10,000 lookups per day, and I believe the next one is 50,000 — you’ll want to check their pricing page for the latest details.

I tried some code for blocking countries, apparently its legit but nothing is ever easy and it still seems to be letting them through. Asking server people if they need to do anything else (the module for it was enabled).

Oops! I switched that off right now, thanks for the tip! I have been testing from a few different ips for testing from GB. But best to follow your advice. I have foreign flood set to True. And noticed a lot of activity that way.

Yes I am considering the first tier to see if that makes it more helpful. I am at 5000 limit, it looks like country specific attacks is the main thing right now. Not sure if your experience with your webstores tallies with that.