[XTR] IP Threat Monitor

[XTR] IP Threat Monitor [Paid] 1.0.21

No permission to buy ($30.00)
Overview FAQ Updates (21) Reviews (2) History Discussion
I have this generated a lot....

Code: 
Server error log
TypeError: stripos(): Argument #1 ($haystack) must be of type string, array given src/addons/XENTR/IPThreatMonitor/Repository/IPThreatLog.php:819
Generated by: Unknown account Dec 23, 2025 at 10:09 PM
Stack trace
#0 src/addons/XENTR/IPThreatMonitor/Repository/IPThreatLog.php(819): stripos(Array, 'Apple')
#1 src/addons/XENTR/IPThreatMonitor/Service/RateLimiter.php(567): XENTR\IPThreatMonitor\Repository\IPThreatLog->isVpnOrProxy('198.163.192.151')
#2 src/addons/XENTR/IPThreatMonitor/Service/RateLimiter.php(111): XENTR\IPThreatMonitor\Service\RateLimiter->checkVpnFirstVisit('198.163.192.151')
#3 src/addons/XENTR/IPThreatMonitor/Listener.php(89): XENTR\IPThreatMonitor\Service\RateLimiter->checkRateLimit()
#4 src/XF/Extension.php(86): XENTR\IPThreatMonitor\Listener::appPubStartEnd(Object(XF\Pub\App))
#5 src/XF/App.php(3366): XF\Extension->fire('app_pub_start_e...', Array, NULL)
#6 src/XF/Pub/App.php(255): XF\App->fire('app_pub_start_e...', Array)
#7 src/XF/App.php(2820): XF\Pub\App->start(true)
#8 src/XF.php(806): XF\App->run()
#9 index.php(23): XF::runApp('XF\\Pub\\App')
#10 {main}
Request state
array(4) {
  ["url"] => string(73) "/threads/when-your-abuser-parent-is-near-the-throws-of-death.66123/page-3"
  ["referrer"] => bool(false)
  ["_GET"] => array(0) {
  }
  ["_POST"] => array(0) {
  }
}
 
Anthony Parsons said:
I have this generated a lot....

Code: 
Server error log
TypeError: stripos(): Argument #1 ($haystack) must be of type string, array given src/addons/XENTR/IPThreatMonitor/Repository/IPThreatLog.php:819
Generated by: Unknown account Dec 23, 2025 at 10:09 PM
Stack trace
#0 src/addons/XENTR/IPThreatMonitor/Repository/IPThreatLog.php(819): stripos(Array, 'Apple')
#1 src/addons/XENTR/IPThreatMonitor/Service/RateLimiter.php(567): XENTR\IPThreatMonitor\Repository\IPThreatLog->isVpnOrProxy('198.163.192.151')
#2 src/addons/XENTR/IPThreatMonitor/Service/RateLimiter.php(111): XENTR\IPThreatMonitor\Service\RateLimiter->checkVpnFirstVisit('198.163.192.151')
#3 src/addons/XENTR/IPThreatMonitor/Listener.php(89): XENTR\IPThreatMonitor\Service\RateLimiter->checkRateLimit()
#4 src/XF/Extension.php(86): XENTR\IPThreatMonitor\Listener::appPubStartEnd(Object(XF\Pub\App))
#5 src/XF/App.php(3366): XF\Extension->fire('app_pub_start_e...', Array, NULL)
#6 src/XF/Pub/App.php(255): XF\App->fire('app_pub_start_e...', Array)
#7 src/XF/App.php(2820): XF\Pub\App->start(true)
#8 src/XF.php(806): XF\App->run()
#9 index.php(23): XF::runApp('XF\\Pub\\App')
#10 {main}
Request state
array(4) {
  ["url"] => string(73) "/threads/when-your-abuser-parent-is-near-the-throws-of-death.66123/page-3"
  ["referrer"] => bool(false)
  ["_GET"] => array(0) {
  }
  ["_POST"] => array(0) {
  }
}
Click to expand...
Hi, We have investigated the error logs you provided. The issue was caused by an unexpected data format (array instead of string) returned from the 3rd party API during the VPN check. We have applied a fix to handle this data correctly. The issue is now resolved and you should no longer see this error. Thank you for reporting this.
 
Osman updated [XTR] IP Threat Monitor with a new update entry:

1.0.11

  • Alert Bug Fixed: Resolved an issue where IP Threat alerts were not visible in the alerts popup/list due to missing content handlers. Alerts are now properly integrated into the notification system.
  • API Data Handling: Fixed a server error log (TypeError) caused by unexpected array data formats in the ProxyCheck.io API response for ASN/Provider fields.
This maintenance release focuses on stability and better integration with XenForo's alert system.
  • ...
Click to expand...

Read the rest of this update entry...
 
Says I can't download. Its been crossed out, even though I just purchased it last night.
 

Attachments

  • Screenshot 2025-12-24 050954.webp
    Screenshot 2025-12-24 050954.webp
    19.2 KB · Views: 6
This is working amazing. Done about 52,000 queries against proxycheck.io in 12hrs, but its worth it and a cheap solution to immediately ban all VPN's from posting or registering. Really impressed so far, especially the speed of which you fix issues. More devs should take note.
 
This is blacklisting a VPN IP for me about every 1.5 seconds so far. Obviously it will slow down once it gets through the bulk of them, just an amazing anti-spam solution for high traffic sites.
 
Osman updated [XTR] IP Threat Monitor with a new update entry:

1.0.12

  • Improvement: Enhanced the logic for "iCloud Private Relay" detection. The system now uses stricter validation (checking for specific identifiers like "Apple Inc." or "iCloud Private Relay") to prevent false positives where unrelated VPNs with similar names were being whitelisted incorrectly.
  • Fix: Fully resolved the data type mismatch (Array vs String) error when processing API responses, ensuring stability for all network types.
This update brings critical...
Click to expand...

Read the rest of this update entry...
 
Osman updated [XTR] IP Threat Monitor with a new update entry:

1.0.13

  • Critical Fix: Implemented a self-healing mechanism for the API Health Check. The system no longer relies on XenForo's internal cache TTL (which could fail in some environments) but uses explicit timestamp validation to auto-recover from API outages.
  • New Feature: Added "Clear API Cache" option to the Logs > Prune Logs page. This allows admins to manually reset the API status via AJAX without reloading the page.
  • Bug Fix: Fixed ArithmeticError: Bit...
Click to expand...

Read the rest of this update entry...
 
Osman updated [XTR] IP Threat Monitor with a new update entry:

1.0.14

  • New Feature: Added Apple iCloud Private Relay IP detection using Apple's official IP list (egress-ip-ranges.csv). The add-on now downloads and caches Apple's official CIDR ranges (refreshed every 24 hours) and checks VPN-flagged IPs against this list. This ensures iCloud Private Relay users are never blocked, regardless of what ProxyCheck.io reports.
  • Critical Fix: Resolved an issue where iCloud Private...
Click to expand...

Read the rest of this update entry...
 
I'm Confused.... (sorry - it happens often!)....

  1. Go to ProxyCheck.io Dashboard → Custom Rules
  2. Click "BIG BUSINESS" category
  3. Add the "Allow iCloud Private Relay" rule
Click to expand...

Where is this category???

1767292252120.webp

Thanks
 
For anyone not understanding the impact this makes, just using the VPN blacklisting alone, let me demonstrate on my site.

My normal uniques is about 1M - 1.5M monthly. Now I have previously thrown everything at this at Cloudflare firewall to get rid of all the rubbish, but spammers in the past months have all shifted to VPN's and I started getting bombarded with VPN traffic, taking my monthly traffic to over 4M uniques. I know its rubbish traffic, and rubbish traffic is just a waste of server resources.

I furthered progress at Cloudflare by taking out the big ASN server farms, Linode, DigitalOcean, Amazon, Microsoft, etc. Not ISP's, just server providers that spammers where using. That got my traffic down to 3M monthly. Still a lot of rubbish.

For the past week I have been using this addon to solely block VPN traffic, as blocking VPN traffic easily at Cloudflare you require an Enterprise plan I believe. Regardless, its expensive for easy VPN blocking at Cloudflare. This is a small cost addon plus a small cost ongoing with Proxycheck, less than $10 monthly. You can see below the past week of my uniques, I have smashed them with this, as the spammers have simply stopped trying for the most part. There are a handful now trying via their normal ISP, but that exposes their ISP IP which is easy to block with no further issue.

Based on below, my next months uniques should be back around that 1M - 1.5M of actual legitimate users, no bots, and this doesn't include good robots, just humans, as I have blocked AI traffic, etc, already. You can see this addons quick stats have now got me to about a 50/50 of traffic being blocked daily, where a week ago it was about 75/25 of bad to good traffic. I expect over the coming week that this shifts more towards 25/75 bad to good traffic.

Simply, they will run out of VPN IP's to use.

I can't recommend this addon enough for those being hit with so much rubbish traffic.

Screenshot 2026-01-02 084447.webp
Screenshot 2026-01-02 084543.webp
 
Osman updated [XTR] IP Threat Monitor with a new update entry:

1.0.15

  • Critical Fix: Resolved MySQL query error [1406]: Data too long for column 'data_value'. This issue occurred on high-traffic sites because XenForo's SimpleCache stores all data in a single database row, which overflowed with thousands of IP check records. VPN/Proxy check results are now securely stored using the add-on's efficient CacheManager (Redis/APCu/File) instead.
  • New Feature: Added "Clear VPN Check Cache" option to the Monitor Dashboard > Prune /...
Click to expand...

Read the rest of this update entry...
 
Something i have just noticed... could well be related since its only started happening in the last couple of weeks, and nothing (to my knowledge had changed otherwise)

Am currently seeing this in the AdminCP. This is from the addon here : https://xenforo.com/community/resources/add-on-update-notifier.9002/

The callbacks for add-on updates seem to be blocked​

Something seems to be blocking the callbacks about new add-on updates and API key changes. This prevents faster updates about new versions.
Instructions on how to unblock it with e.g. Cloudflare
(This message can be disabled from the add-on's options)
Click to expand...

I have added the ip's listed to the whitelist, however no difference.

I am saying they may be linked - i realise that this addon blocks incoming connections, however is there a chance that it is also doing something with the above also?

I will also post in the addon update notifier thread.

Thanks.
 
Hi,

Thank you for the detailed report.

Our add-on should NOT block trusted IPs. The code flow is:
  1. Check if IP is in Trusted IPs list → If yes, skip ALL checks (including blacklist)
  2. Check if IP is blacklisted → This only happens if IP is NOT trusted
Possible causes:

1. IP Format Issue: Make sure you're entering the exact IP addresses from the callback bot page. Our Trusted IPs option supports:
  • Single IPs: 1.2.3.4
  • CIDR ranges: 1.2.3.0/24
2. Previously Blacklisted: If the callback IPs were blacklisted BEFORE you added them to Trusted IPs, the cache might still have old data.
  • Go to Monitor Dashboard → Search for the callback IPs
  • If any show as "Blacklisted", manually unblock them
  • Then add them to Trusted IPs in Options
3. Cache Issue: After adding Trusted IPs, go to Monitor Dashboard → Prune / Clear Logs → Clear API Cache to refresh the trusted IPs cache.

4. Different IP: The callback server might be using a different IP than listed. You can check your Monitor Dashboard logs to see which IPs are actually being blocked.

Quick Diagnostic:
  1. What is the exact IP address of the callback server?
  2. Is that IP showing as "Blacklisted" in your Monitor Dashboard?
  3. Did you add it to Trusted IPs in Options → IP Threat Monitor → Trusted IPs?
If you can provide the specific callback IPs, I can help you troubleshoot further.
 
You must log in or register to reply here.
Back
Top Bottom