AbuseIPDB Integration module

[HeathenMagic]

I had a customer say they tried to get on site for a few days, but it said 'access denied'. I am not sure what the message screen for abuse is actually, when blocked. They were able to get on okay at weekend though. I would say there was a massive bot scraping operation going on around same time apparently, I told server and they said they had come across this for the other sites on their systems. So they blocked that whole range. I don't have country flood enabled, do you think octet flood or session rate settings might be culprit? I am guessing the two are related, maybe the customer got caught in the crossfire with this big bot attack thing. Thanks in advance.

[marcopolo]

I had a customer say they tried to get on site for a few days, but it said 'access denied'. I am not sure what the message screen for abuse is actually, when blocked. They were able to get on okay at weekend though. I would say there was a massive bot scraping operation going on around same time apparently, I told server and they said they had come across this for the other sites on their systems. So they blocked that whole range. I don't have country flood enabled, do you think octet flood or session rate settings might be culprit? I am guessing the two are related, maybe the customer got caught in the crossfire with this big bot attack thing. Thanks in advance.

If it had been a session rate limiting block, that would show up as a permanent Deny from <IP> entry in the .htaccess under the AbuseIPDB section. Since you don’t see their IP there, it wasn’t SRL.

You can see exactly what the customer would have seen by using the plugin’s Test Mode—that forces the “Access Denied” message regardless of score.

Another possibility is that the customer was on a VPN or mobile network where IPs tend to rotate. Those often carry higher AbuseIPDB scores and can be blocked even if you’re not using country flood.

To be sure, I’d recommend turning on logging in the plugin. That way you can look up their IP and see whether it was caught by:

Score block (exceeded your confidence threshold)

Octet flood (2- or 3-octet prefix got busy during the scrape)

Or if it was just your host’s server-level range ban

A couple other good practices from the README:

Whitelist trusted customer IPs if needed.

Keep an eye on the Who’s Online shields—they’ll show if it was score, blacklist, flood, or country that triggered.

Remember the Score-Safe rule: even if a flood threshold is hit, an IP still needs to meet the minimum score before blocking occurs. That helps avoid catching bursts of legit traffic like newsletters or sales.

If you’re not sure which feature bit, the log files are your best friend (abuseipdb_blocked_*, abuseipdb_session_blocks.log, etc.).

And yes—all of this is outlined in the README, so it’s worth a quick re-read whenever you’re tracking down one of these cases.

[HeathenMagic]

If it had been a session rate limiting block, that would show up as a permanent Deny from <IP> entry in the .htaccess under the AbuseIPDB section. Since you don’t see their IP there, it wasn’t SRL.

You can see exactly what the customer would have seen by using the plugin’s Test Mode—that forces the “Access Denied” message regardless of score.

Another possibility is that the customer was on a VPN or mobile network where IPs tend to rotate. Those often carry higher AbuseIPDB scores and can be blocked even if you’re not using country flood.

To be sure, I’d recommend turning on logging in the plugin. That way you can look up their IP and see whether it was caught by:

Score block (exceeded your confidence threshold)

Octet flood (2- or 3-octet prefix got busy during the scrape)

Or if it was just your host’s server-level range ban

A couple other good practices from the README:

Whitelist trusted customer IPs if needed.

Keep an eye on the Who’s Online shields—they’ll show if it was score, blacklist, flood, or country that triggered.

Remember the Score-Safe rule: even if a flood threshold is hit, an IP still needs to meet the minimum score before blocking occurs. That helps avoid catching bursts of legit traffic like newsletters or sales.

If you’re not sure which feature bit, the log files are your best friend (abuseipdb_blocked_*, abuseipdb_session_blocks.log, etc.).

And yes—all of this is outlined in the README, so it’s worth a quick re-read whenever you’re tracking down one of these cases.

Thanks so much for your reply! I just checked the customer account today, and it seems it is a different IP login than it was yesterday. They said not on VPN, so must be a mobile network. Both were BT. I didn't realise VPN would be high score rated sometimes. I guess some VPNs are more questionable than others. Perhaps I could increase threshold score from 41.

[OldNGrey]

I use the following steps and have reduced the spam accounts, email abuse etc to a minimum:
threshold set to 45;
notice on front page re use of VPN and octet blocking by Wikimedia; and
I also use AccessBlocker on all 'Contact' forms.This can block a lot of tor sites and VPNs

[HeathenMagic]

Not sure if an intermittent glitch, but doing an order for a customer in their account (pay via phone, select cash as method and put through) once logged in it showed the forbidden access screen. I tried my test account and the same thing for that also. Though it was 2 hours after abuseipdb daily limit exhausted. Though doing the same process just now, it is fine. I am guessing it may be AbuseIPDB service may do this due to exhausted access?
I also tried after exhaustion on mobile data, and the same forbidden once logging in. But not logging, it seemed okay.

[Shop Suey]

Did you check the IP score at their website?

[marcopolo]

Did you check the IP score at their website?

When the AbuseIPDB daily quota was exhausted, older builds could treat the “-1” score in a way that kept incrementing flood counters on each refresh. That could tip your 2-octet/3-octet thresholds and show the Forbidden page especially right after login.

This is now fixed in v4.0.9:

“-1” (API exhausted) is now treated as safe (like score 0),

flood is seeded once (no per-refresh increments), and

no flood-based blocking occurs while the API is exhausted.

Download and install the updated v4.0.9 module available on GitHub: https://github.com/CcMarc/AbuseIPDB/...PDB_v4.0.9.zip

[marcopolo]

Not sure if an intermittent glitch, but doing an order for a customer in their account (pay via phone, select cash as method and put through) once logged in it showed the forbidden access screen. I tried my test account and the same thing for that also. Though it was 2 hours after abuseipdb daily limit exhausted. Though doing the same process just now, it is fine. I am guessing it may be AbuseIPDB service may do this due to exhausted access?
I also tried after exhaustion on mobile data, and the same forbidden once logging in. But not logging, it seemed okay.

When the AbuseIPDB daily quota was exhausted, older builds could treat the “-1” score in a way that kept incrementing flood counters on each refresh. That could tip your 2-octet/3-octet thresholds and show the Forbidden page especially right after login.

This is now fixed in v4.0.9:

“-1” (API exhausted) is now treated as safe (like score 0),

flood is seeded once (no per-refresh increments), and

no flood-based blocking occurs while the API is exhausted.

Download and install the updated v4.0.9 module available on GitHub: https://github.com/CcMarc/AbuseIPDB/...PDB_v4.0.9.zip

[siliconbug]

In v2.1.2 (for ZC 1.5.8),
what's the difference between "Enable IP Blacklist File?" and "IP Address: Blacklist"?

[marcopolo]

In v2.1.2 (for ZC 1.5.8),
what's the difference between "Enable IP Blacklist File?" and "IP Address: Blacklist"?

The admin blacklist setting lets you manually enter specific IPs to block right in the configuration panel.

If you enable the IP Blacklist File, the module will also check that file for matches and once that’s enabled, you can add IPs directly to the file or blacklist them instantly from the “Who’s Online” page using the 🚫 button.