IniLerm

hi @stippeltje404

If you have a spare moment, leaving a 5-star review would be amazing. It helps us grow and reach more people who need simple, powerful security.

👉 Rate Advanced IP Blocker here

• This reply was modified 1 day, 16 hours ago by IniLerm.

Hello @ambientblog,

Dealing with aggressive scrapers and crawlers hitting pagination URLs (like /page/xx/) is a very common battle! Fortunately, Advanced IP Blocker has several built-in layers specifically designed to stop this kind of automated traffic without hurting your real users.

Here is the recommended configuration to clean up your traffic:

1. Enable the Community Defense Network Go to Settings > AIB Community Defense Network and turn on all the switches. Scrapers often use the same IP ranges across multiple sites; this feature will automatically block IPs that have already been flagged as malicious by our community.

2. Enable User-Agent Protection Go to Settings > User-Agent Protection and make sure you activate:

• Verify Known Bots
• Verify AI Bots (CIDR)
• Verify Monitoring Bots (IP List) This ensures that bots claiming to be legitimate search engines are actually real. It will drop fake bots and aggressive unverified crawlers immediately.

3. Set up a JavaScript Challenge (The ultimate scraper killer) If these scrapers are triggering your security rules, go to the Attack Signature Engine and configure the mitigation action to JS automatic challenge / transparent (or use Turnstile / hCaptcha if you have them configured). Why this works: Most automated scrapers and dumb crawler scripts cannot execute JavaScript. They will fail the challenge and be blocked, while your real human visitors will pass the transparent challenge seamlessly without even noticing.

4. Block Specific Scrapers Manually If you’ve checked your analytics and identified a specific unwanted scraper (for example, Sogou web spider/4.0...), you can block it directly. Go to Blocking Rules > User Agents and simply add a keyword like Sogou to your blocked list.

A quick reminder about your stats: Please keep in mind that seeing some crawler traffic on your /page/xx/ URLs in your stats is completely normal. Legitimate search engines (like Googlebot or Bingbot) need to crawl your pagination to index your older posts properly. As long as you have “Verify Known Bots” enabled (Step 2), the good bots will do their job safely, and the malicious scrapers will be kept out.

Hope this helps you clean up your traffic! Let us know if you need any help setting this up.

Hi Greg,

First of all, thank you again for the incredibly detailed feedback and for taking the time to share your own traffic data regarding Go-http-client—that is exactly the kind of field intelligence that helps us improve the plugin for everyone!

Regarding your points, here is our breakdown:

1. The Default UA Lists Divergence: You were absolutely right. The hardcoded lists had diverged between class-advaipbl-main.php and class-advaipbl-admin-pages.php. Since version 8.13.3 was already pushed to the repository earlier today, this change isn’t in there just yet—but your catch was so good that we have immediately committed the fix for our upcoming 8.13.4 release. In 8.13.4, the UI page will dynamically call ADVAIPBL_Main::get_instance()->get_default_user_agents(), guaranteeing there is only one source of truth and the lists will never drift apart again.

2. Targeting Go-http-client on specific paths: Your reasoning is spot-on. Leaving it unblocked globally (to prevent breaking internal microservices) while blocking it on sensitive endpoints is the perfect approach. You can easily set this up right now using our Advanced Rules engine! Simply create a new rule with two conditions:

• User-Agent -> contains -> Go-http-client
• URI -> contains -> /wp-json/wp/v2/users/ (You can also use regex to include /wp-login.php). This keeps the protection exactly where it earns its place without the global false-positive risk.

3. Whitelisted User-Agents and Spoofing: Since we are on the topic of User Agents, please remember that the “Whitelisted User-Agents List” takes absolute precedence and allows all traffic if a match is found. Because UAs are trivially easy to spoof (attackers often impersonate Googlebot), we recommend using this whitelist very sparingly. Instead, to ensure official services aren’t blocked, we highly recommend keeping the verification options enabled under Security -> Core Protections -> User-Agent Protection:

• Verify Known Bots
• Verify AI Bots (CIDR)
• Verify Monitoring Bots (IP List) These checks perform reverse DNS/IP lookups to cryptographically prove the bot is legitimate before allowing it through.

4. New WAF Features in 8.13.3: Since you are likely updating to 8.13.3 today, we want to gently remind you to check your Security -> Core Protections -> Web Application Firewall (WAF) settings and ensure the newest engines are active:

• Enable WAF
• Intelligent Zero-Day Sync
• Cloud Advanced Rules Sync These active syncs will automatically pull down our latest JSON zero-day rules (like the recent critical Gravity Forms and Elementor Pro patches).

5. Exclusion Box for UA Scoring: This is a brilliant suggestion! We completely agree that a dedicated URI exclusion box for User-Agent scoring (similar to the 404/403 exclusions) would be very useful for the exact platform endpoints you described. We have added this to our roadmap and will implement it alongside the UA list fix in the upcoming 8.13.4 release.

Thank you once again for your fantastic collaboration!

Hi Greg (@thewatchman3),

Thank you so much for this detailed and excellent bug report. You are absolutely right.

okhttp and Dalvik/ are legitimate Android platform signatures and should never have been active by default. While they can occasionally be spoofed by scrapers, the risk of blocking legitimate users (especially with automated background requests like App Links verification) is too high and goes against our core philosophy of avoiding false positives.

We have reviewed the entire default User-Agent list and made the following changes:

Commented out okhttp and Dalvik/ (they are now #okhttp and #Dalvik/ in the default list).
We also took the opportunity to comment out Go-http-client and PostmanRuntime, as these are frequently used by legitimate microservices and developers.
These changes are already committed and will be included in our upcoming 8.13.3 release.

As you correctly pointed out, if an administrator notices a specific malicious bot abusing okhttp against a specific endpoint (like a login page), they can always create a targeted Advanced Rule just for that route rather than relying on a global UA block.

Thank you again for helping us make Advanced IP Blocker better!

• This reply was modified 2 weeks, 2 days ago by IniLerm.
• This reply was modified 2 weeks, 2 days ago by IniLerm.

Hi @sawontheboss4,

First of all, I want to sincerely apologize for the inconvenience this issue has caused you. We take this very seriously, and I really appreciate your patience and detailed feedback regarding the CPGuard block.

We have completely refactored the way the File Integrity Monitor stores and loads malware signatures. The dictionary is no longer hardcoded into the plugin files, but rather dynamically fetched and securely stored in your database. This architectural change ensures that aggressive server antiviruses like CPGuard will no longer falsely flag our plugin as a threat during installation or scanning.

We have just released Version 8.13.2 with this hotfix. Although it might take up to 6 hours to appear in your WordPress update dashboard, the direct package is already available on the official servers.

If you have a moment, it would be incredibly helpful if you could test it manually to confirm that CPGuard now allows the installation perfectly.

You can download the official package here: https://downloads.wordpress.org/plugin/advanced-ip-blocker.8.13.2.zip

How to install it manually:

1. Download the .zip file from the link above.
2. Go to your WordPress Dashboard -> Plugins -> Add New Plugin.
3. Click on the Upload Plugin button at the top.
4. Choose the downloaded .zip file and click Install Now.
5. WordPress will detect that the plugin is already installed and will ask you if you want to replace it. Click on “Replace current with uploaded”.
6. Once completed, make sure the plugin is activated.

Please let me know how the installation goes for you. If everything is green on your end, we’ll consider this false positive issue permanently resolved.

Thank you again for helping us make the plugin better!

Best regards,

Inilerm

• This reply was modified 2 weeks, 5 days ago by IniLerm.
• This reply was modified 2 weeks, 5 days ago by IniLerm.

Hello sawontheboss4,

Thank you for providing the detailed CPGuard log! This is a known **False Positive** from your server’s antivirus software (CPGuard).

**What happened:**

In version 8.13.0, we introduced a highly advanced File Integrity and Malware Scanner. To detect hackers, the class-advaipbl-fim-engine.php file contains a dictionary of known malware signatures. CPGuard scanned our plugin, found this dictionary of bad words, and mistakenly thought our scanner was a virus.

**Immediate Solution:**

1. Please whitelist the file class-advaipbl-fim-engine.php in CPGuard (or ask your hosting provider to do it for you).

2. Restore the file from the CPGuard quarantine, or simply reinstall the Advanced IP Blocker plugin (your settings will not be lost).

We are already working on a patch (8.13.1) that uses a different encryption method for our malware dictionary so that server antiviruses will completely ignore it.

Thank you for your patience and for reporting this!

💡 Tip for users experiencing missing files after a failed auto-update:

If your server times out or fails to extract all files during a WordPress plugin update, you might be left with an incomplete installation. Here are three ways to quickly fix this and restore your site:

1. Reinstall via WordPress Admin (Easiest) If you still have access to your WordPress dashboard, go to Plugins -> Add New Plugin, search for Advanced IP Blocker, and click Install Now again to force a fresh download.

2. Reinstall via ZIP Upload If the first method doesn’t work, you can manually overwrite the broken files:

• Download the latest version of the plugin as a .zip file from the official repository here.
• Go to your WordPress dashboard: Plugins -> Add New Plugin -> Upload Plugin.
• Upload the .zip file. WordPress will detect the existing folder and ask if you want to replace it. Click Replace current with uploaded.

3. Upload the Missing File Manually (Advanced Users) If your site is completely locked out (Fatal Error / White Screen of Death) and you can’t access wp-admin, you can use FTP/SFTP or your Hosting’s File Manager:

• You can find the raw source code for any specific version (e.g., 8.12.2) in the SVN repository: https://plugins.svn.wordpress.org/advanced-ip-blocker/tags/8.12.2/includes/
• Download the specific file mentioned in your error log (for example, class-advaipbl-ajax-handler.php).
• Upload it directly to the corresponding folder on your server: /wp-content/plugins/advanced-ip-blocker/includes/.

(Note: Starting from our next release, we have completely redesigned our file loader. If a file is missing in the future due to a server glitch, the plugin will gracefully deactivate itself instead of causing a Fatal Error, keeping your site online).

Hi Oleg,

Thank you very much for taking the time to report this issue in detail and for your patience. We have thoroughly investigated the case and successfully identified and fixed the bug affecting the threshold blocking system (404/403/Login).

We will be releasing update 8.12.2 within the next 24 to 48 hours (possibly sooner), which includes this fix. With this update, the blocking system will work perfectly and be much more robust.

We greatly appreciate your help. Thanks to reports like yours, we can keep improving the plugin for everyone!

Best regards, The Advanced IP Blocker Team