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)!