AbuseIPDB Integration module

[lat9]

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,

The problem, IMO, with the proposed approach is the requirement for the site's autoloading to occur as it requires database accesses to determine whether/not to shut down the request.

I realize the non-Apache risk with the alternative solution, but it's probably the best choice to shut down the unwanted accesses before additional server resources (i.e. database and file-system) are required.

For either approach, you could use an auto-loader and load your processing after breakpoint 50 (where the database connection is made and configuration settings read) and prior to breakpoint 70 (where the session is established).

[marcopolo]

The problem, IMO, with the proposed approach is the requirement for the site's autoloading to occur as it requires database accesses to determine whether/not to shut down the request.

I realize the non-Apache risk with the alternative solution, but it's probably the best choice to shut down the unwanted accesses before additional server resources (i.e. database and file-system) are required.

For either approach, you could use an auto-loader and load your processing after breakpoint 50 (where the database connection is made and configuration settings read) and prior to breakpoint 70 (where the session is established).

Thanks for the feedback—much appreciated. I’ve decided to go with the .htaccess method for now to catch these before they hit the server resources. I agree, it’s the cleanest way in the current setup even if not fully portable.

[marcopolo]

New Release: AbuseIPDB v4.0.3

🚨 What’s New:

- Advanced Session Rate Limiting: Protect your site from bots creating sessions too rapidly! IPs exceeding the threshold (default: 100 sessions in 60 seconds) are blocked via .htaccess and logged in `logs/abuseipdb_session_blocks.log`. Configure the threshold, time window, and reset period (default: 5 minutes) in the admin settings. Blocked IPs remain blocked until manually removed from .htaccess by the admin.

- Enhanced Flood Tracking Reset: Building on v4.0.2, flood tracking now resets per type (2-octet, 3-octet, country, foreign) after the defined reset period, ensuring previously flagged IPs are recounted if they return later.

🚀 Visual Update (from v4.0.2):

- Monitor threats effortlessly with color-coded shields in the Who's Online page, including new colors for flood blocks (teal for domestic, brown for foreign) and superscripts for 2F/3F floods.

📝 Notes:

- Session rate limiting is designed for Apache2 servers, as it uses .htaccess to block IPs. For non-Apache servers (e.g., Nginx), you’ll need to implement alternative rate-limiting solutions.
- Ensure your .htaccess file is writable (e.g., `chmod 664 .htaccess` and `chmod 775` for the directory) for session rate limiting to work.
- The session rate limiting log (`abuseipdb_session_blocks.log`) is generated regardless of the general logging setting, so you can always review blocked IPs.

Download the latest version and check out the full details on [GitHub](https://github.com/CcMarc/AbuseIPDB/releases/tag/v4.0.3)!

[marcopolo]

New Release: AbuseIPDB v4.0.5

🚨 What’s New:

v4.0.5: Updated admin dashboard widget to display Session Rate Limiting blocks in .htaccess for easy admin visibility when they occur.

v4.0.4: Bug Fix - resolved country code population bug and removed duplicate config setting in installer.

Download the latest version and check out the full details on [GitHub](https://github.com/CcMarc/AbuseIPDB/releases/tag/v4.0.5)!

[marcopolo]

New Release: AbuseIPDB v4.0.6

🚨 What’s New:

v4.0.6: Improved session rate limiting by using a new abuseipdb_actions table to queue IPs for blocking, reducing .htaccess write delays and preventing duplicate log entries.

Download the latest version and check out the full details on [GitHub](https://github.com/CcMarc/AbuseIPDB/releases/tag/v4.0.6)!

[HeathenMagic]

hello there,
Thanks for this module, you recommended. I get the following error log from whos online:-

Table '****_zen.zen_abuseipdb_cache' doesn't exist'

I renamed the four databases and put zen_ in front, that error goes and whos online works. Just wondering, if I did right doing the other three tables the same? Thanks :-)

EDIT I renamed back as it seems to stop the site working, so I turned off abuseipdb for now. On 4.06 version. I think I am not the norm in having zen_ prefix, which I have had this issue before actually.

[marcopolo]

hello there,
Thanks for this module, you recommended. I get the following error log from whos online:-

Table '****_zen.zen_abuseipdb_cache' doesn't exist'

I renamed the four databases and put zen_ in front, that error goes and whos online works. Just wondering, if I did right doing the other three tables the same? Thanks :-)

EDIT I renamed back as it seems to stop the site working, so I turned off abuseipdb for now. On 4.06 version. I think I am not the norm in having zen_ prefix, which I have had this issue before actually.

I've just released v4.0.8, which adds full support for Zen Cart table prefixes via the DB_PREFIX constant. You no longer need to rename any database tables manually — in fact, doing so will cause the module to break.

To fix the issue:

Revert the following database tables back to their original names — or simply delete them. The installer will automatically recreate them during the upgrade:

abuseipdb_cache
abuseipdb_flood
abuseipdb_maintenance
abuseipdb_actions

Download and install the updated v4.0.8 module (available on GitHub - Download v4.0.8).

The module now automatically adapts to your store’s prefix settings, and the “table doesn’t exist” error should be fully resolved.

Let me know if you run into anything else — I appreciate the feedback!

[HeathenMagic]

I've just released v4.0.8, which adds full support for Zen Cart table prefixes via the DB_PREFIX constant. You no longer need to rename any database tables manually — in fact, doing so will cause the module to break.

To fix the issue:

Revert the following database tables back to their original names — or simply delete them. The installer will automatically recreate them during the upgrade:

abuseipdb_cache
abuseipdb_flood
abuseipdb_maintenance
abuseipdb_actions

Download and install the updated v4.0.8 module (available on GitHub - Download v4.0.8).

The module now automatically adapts to your store’s prefix settings, and the “table doesn’t exist” error should be fully resolved.

Let me know if you run into anything else — I appreciate the feedback!

Thanks for the update. I deleted the tables first, uninstalled, then installed 4.0.8 via plugin manager. Unfortunately, I still get a similar error:-

PHP Fatal error: MySQL error 1146: Table '****.zen_abuseipdb_actions' doesn't exist :: SELECT ip FROM zen_abuseipdb_actions ==> (as called by) /zc_plugins/AbuseIPDB/v4.0.8/catalog/includes/classes/observers/abuseipdb_observer.php on line 92 <== in /includes/classes/db/mysql/query_factory.php on line 733.

Maybe it is my setup? The tables are without prefix, I can see 4. They are at top of list as they are alphabetically first. Hope this helps.

[marcopolo]

Thanks for the update. I deleted the tables first, uninstalled, then installed 4.0.8 via plugin manager. Unfortunately, I still get a similar error:-



Maybe it is my setup? The tables are without prefix, I can see 4. They are at top of list as they are alphabetically first. Hope this helps.

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!

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