AbuseIPDB Integration module

[marcopolo]

I've updated the installer — I had missed a section.
Please re-download the latest ZIP for v4.0.8 — the fix is included now. Let me know if anything else comes up!

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.

[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.