AbuseIPDB Integration module

[dbltoe]

You might want to move that message inside the INSTALLATTION AND UPGRADE section.

[marcopolo]

Please review your README.md and identify the steps from an encapsulated plugin to a newer plugin. Otherwise, others will lose their API data as we did.

I would note that, normally, a plugin notifies the owner of an update, the update is done, and the option to clean old files follows the upgrade. https://docs.zen-cart.com/dev/plugin...ins/upgrading/

As stated, the instructions are clear — you need to uninstall. I could’ve made it an upgrade, but that would’ve meant a lot more work for the installer. Unfortunately, this means you’ll lose your database data. It is possible to skip uninstalling certain tables, but that’s more of an advanced option. Since I’m offering this for free, I don’t have the time to troubleshoot those kinds of setups. This update adds a lot of new features, so it had to be done this way.

[marcopolo]

Posting again so everyone is clear on this:

INSTALLATION AND UPGRADE
Major Update Notice: If you are upgrading from v3.0.4 or earlier, you must uninstall the previous module before installing v4.0.0.
⚡ Important: Be sure to screen-capture your existing settings before uninstalling AbuseIPDB v3.0.4 or lower to preserve your configuration.

Advanced Uninstallation: Preserving Cache Database
If you are an advanced user and do not want to lose your cache database when uninstalling the plugin, you can modify the installer to preserve the database tables (abuseipdb_cache, abuseipdb_maintenance, and abuseipdb_flood). Follow these steps:

Open the installer file for your current version (e.g., ScriptedInstaller.php) in a text editor.
Locate the executeUninstall() method near the end of the file.
Delete the following lines to prevent dropping the tables during uninstallation:

$this->executeInstallerSql("DROP TABLE IF EXISTS " . TABLE_ABUSEIPDB_CACHE);
$this->executeInstallerSql("DROP TABLE IF EXISTS " . TABLE_ABUSEIPDB_MAINTENANCE); 

Save the file and proceed with the uninstallation via the Zen Cart admin panel. This will remove the plugin settings but leave the tables intact.
When you install the new version, the installer will skip creating these tables if they already exist, preserving your data.


🛡️ Major Release – AbuseIPDB v4.0.0

This version introduces advanced flood detection and blocking, giving you full control over how your site handles aggressive traffic patterns.

🚨 What’s New:
Flood Blocking by IP Range
You can now automatically block 2-octet (e.g., 192.168.*) or 3-octet (e.g., 192.168.1.*) IP ranges.
Example: If 192.168.x.x exceeds the request limit (default 25 hits in 30 minutes), the entire 2-octet range will be blocked. If 30 minutes pass with no further hits, the block resets.

Country & Foreign Blocking
Works the same way — if traffic from a country exceeds the flood threshold, the country is temporarily blocked.
You can choose to allow low-score IPs through by setting a minimum AbuseIPDB score (or set it to 0 to block all traffic from that country).
Manual country blocking is also supported.

High Score Caching
New AbuseIPDB high-score cache prevents repeated API calls. If an IP already scored above the block threshold, it won’t be rechecked for X days (default: 7).

New Visual Shields in Who’s Online
Clearly see why an IP is being blocked:

🔴 Red – Score-blocked by AbuseIPDB

🟣 Purple – Manually blacklisted

🔵 Blue – Manually country-blocked

🟠 Orange – Flood-blocked (range, country, or foreign)


Personal Recommendation:
For daily use, I recommend enabling only the 2-octet, 3-octet, and foreign flood protection.
Use country-based blocking only during an active attack — it will block IPs from your default country as well.

NOTE:
The 2-octet and 3-octet flood logic will block IPs even from your default country — there's no skip setting for those.
This is by design, as tight-range IP floods are typically bot attacks.
I may add an option to bypass default-country IPs in a future version.

Enjoy!

[marcopolo]

Posting again so everyone is clear on this:

INSTALLATION AND UPGRADE
Major Update Notice: If you are upgrading from v3.0.4 or earlier, you must uninstall the previous module before installing v4.0.0.
⚡ Important: Be sure to screen-capture your existing settings before uninstalling AbuseIPDB v3.0.4 or lower to preserve your configuration.

Advanced Uninstallation: Preserving Cache Database
If you are an advanced user and do not want to lose your cache database when uninstalling the plugin, you can modify the installer to preserve the database tables (abuseipdb_cache, abuseipdb_maintenance, and abuseipdb_flood). Follow these steps:

Open the installer file for your current version (e.g., ScriptedInstaller.php) in a text editor.
Locate the executeUninstall() method near the end of the file.
Delete the following lines to prevent dropping the tables during uninstallation:

$this->executeInstallerSql("DROP TABLE IF EXISTS " . TABLE_ABUSEIPDB_CACHE);
$this->executeInstallerSql("DROP TABLE IF EXISTS " . TABLE_ABUSEIPDB_MAINTENANCE); 

Save the file and proceed with the uninstallation via the Zen Cart admin panel. This will remove the plugin settings but leave the tables intact.
When you install the new version, the installer will skip creating these tables if they already exist, preserving your data.


🛡️ Major Release – AbuseIPDB v4.0.0

This version introduces advanced flood detection and blocking, giving you full control over how your site handles aggressive traffic patterns.

🚨 What’s New:
Flood Blocking by IP Range
You can now automatically block 2-octet (e.g., 192.168.*) or 3-octet (e.g., 192.168.1.*) IP ranges.
Example: If 192.168.x.x exceeds the request limit (default 25 hits in 30 minutes), the entire 2-octet range will be blocked. If 30 minutes pass with no further hits, the block resets.

Country & Foreign Blocking
Works the same way — if traffic from a country exceeds the flood threshold, the country is temporarily blocked.
You can choose to allow low-score IPs through by setting a minimum AbuseIPDB score (or set it to 0 to block all traffic from that country).
Manual country blocking is also supported.

High Score Caching
New AbuseIPDB high-score cache prevents repeated API calls. If an IP already scored above the block threshold, it won’t be rechecked for X days (default: 7).

New Visual Shields in Who’s Online
Clearly see why an IP is being blocked:

🔴 Red – Score-blocked by AbuseIPDB

🟣 Purple – Manually blacklisted

🔵 Blue – Manually country-blocked

🟠 Orange – Flood-blocked (range, country, or foreign)


Personal Recommendation:
For daily use, I recommend enabling only the 2-octet, 3-octet, and foreign flood protection.
Use country-based blocking only during an active attack — it will block IPs from your default country as well.

NOTE:
The 2-octet and 3-octet flood logic will block IPs even from your default country — there's no skip setting for those.
This is by design, as tight-range IP floods are typically bot attacks.
I may add an option to bypass default-country IPs in a future version.

Enjoy!

Important Note:
Actually, do not keep the old tables — the new version of the plugin includes an updated abuseipdb_cache table with a new column I forgot to mention (flood_tracked).

[marcopolo]

Ignore the post before this one where I gave you a option to preserve your tables that will not work. The new version of the plugin includes an updated abuseipdb_cache table with a new column I forgot to mention (flood_tracked).

[pilou2]

I submitted a PR on GitHub for a new installer version that should resolve most of your problems.
If you adopt it, you still have to update the install explanation in the readme...

[marcopolo]

Plugin Manager was still showing 3.0.4, did an uninstall, zc_plugins directory showed only 4.0.0 as I had done the cleanup.

Reinstalled using Plugin Manager and all is fine. Got the 47 and the Enable High Score...

New Version Available: AbuseIPDB v4.0.1

The latest version is now available on GitHub: v4.0.1
This update adds full upgrade support — you can now upgrade without uninstalling.

Special thanks to @piloujp for contributing to the improved upgrade logic.

[@swguy] — please disregard my previously submitted v4.0.0 release. I’ll be submitting v4.0.1 instead.

GitHub: https://github.com/CcMarc/AbuseIPDB

[pilou2]

I installed 4.01 release over an old version without any problem. :)
I just have one question, why do you keep version number in configuration table? With encapsulated plugins, Plugin Manager saves this information in plugin_control_version table already.

[marcopolo]

I installed 4.01 release over an old version without any problem. :)
I just have one question, why do you keep version number in configuration table? With encapsulated plugins, Plugin Manager saves this information in plugin_control_version table already.

You're absolutely right — I could pull it from the plugin_control_version table. The encapsulated plugin logic is still fairly new to me, and I haven’t fully transitioned to Zen Cart v2.1.0 yet — I’m in the middle of that upgrade process. The version number in the configuration table was part of the older approach, and I just left it in place when converting the plugin to an encapsulated version.

[marcopolo]

I’m exploring a possible new feature for the AbuseIPDB plugin to prevent bots from rapidly creating sessions in Zen Cart (e.g., 1000+ sessions in a short time), which can overload the server. I’ve seen this happen a few times—bots create thousands of sessions and cause major performance issues. Since Zen Cart’s session_start() in application_top.php runs before the plugin can intervene, we need to block these requests before session creation.

Goal:
Block session creation for IPs that exceed a rate threshold (e.g., 100 sessions in 1 minute), while allowing normal browsing patterns (e.g., 100 sessions over 30 minutes).

Proposed Approach:

Use an auto-loader or similar method to run a check before session_start() in application_top.php.

Track session rates per IP in TABLE_ABUSEIPDB_CACHE (session count and window start time).

Use a sliding window (e.g., 60 seconds): increment count per request, reset after window expires.

If the count exceeds the threshold, return a 403 Forbidden response and exit.

Alternative (Not Preferred):
Dynamically write deny rules to .htaccess to block IPs at the Apache level before PHP runs. We’d prefer to avoid this for compatibility with non-Apache servers.

This issue is rare but impactful, so we need to address it. I’d really appreciate input from anyone who’s tackled similar problems, or ideas on the cleanest and most portable way to intercept or throttle session creation before session_start() runs. Any advice on standard mechanisms, code examples, or pitfalls to watch out for would be greatly appreciated!

If there isn’t a clean way to accomplish this in the current Zen Cart architecture, I’d suggest considering it for a future version. It would be ideal if Zen Cart provided a standard pre-session hook or filtering mechanism—either in the core or through a well-documented extension point—so modules like AbuseIPDB (or others) can intercept and block abusive requests before sessions are created. This would make handling rate-limiting and abuse much more robust and portable going forward.

Thanks,