Multiple Site Scan Errors
-
We have been experiencing Site Scan errors for the past 3 days. No back-end changes have been made to our websites.
The Site Scan Error messages vary. This is what we’re seeing:
We are also getting Site Scan results that say “Clean” but a red dot (failure) is displayed.
For now, we’ll assume iThemes or Sucuri are having server issues. Hopefully, they haven’t been hacked! LOL
Anybody experiencing the same?
Cheers!
-
Update:
We continue to experience issues with iThemes Security Site Scanner for Malware, etc.
Today, we noticed the following:
(1) An auto-scan for malware revealed that our site is clean. However, we keep getting a “red” dot. Click here for details.
(2) According to this article, we should also be seeing results for “Blocklist.” Well, none are being detected nor displayed. [Note: The scanner should say or display “Blacklist” not “Blocklist” – a typo]
(3) The auto-scan for malware – apparently – is now linked to Googlebot’s site scanner, not Sucuri’s (as this reference and this one suggest). We confirmed this by looking at our log in the back-end. This is what we found: Click here, here, and here.
So, in short, it appears the developers of iThemes have changed a few things in the back-end without public knowledge and/or are experiencing issues with Sucuri and Google.
Anyone experiencing the same? If so, how were you able to fix the issue(s)?
Cheers!
Update:
We also learned that those who use Cloudflare may be affected by the issue(s) reported above.
Cloudflare offers a bot-fighting tool called, “Bot Fight Mode.” To access it, go to: Cloudflare > Firewall > Tools > Bot Fight Mode.
“Bot Fight Mode” – when activated – injects a small, necessary js file into your website which triggers a false-positive when running https://sitecheck.sucuri.net. You’ll get a 503 server error or a “Malware” found message.
We checked with Sucuri, SiteGround (our host), and Cloudfare about this. Their answers:
Sucuri: “We know nothing about this.” No investigations performed. Support was poor.
SiteGround: They double-checked our account for Malware and functionality issues. Nothing found.
Cloudflare: They confirmed that “Bot Fight Mode” is working as intended and that Sucuri needs to review the impact of Cloudflare’s “Bot Fight Mode” on Sucuri’s bots used for malware site-scanning. They need to update their logic and site-scan algorithms to ensure they whitelist Cloudflare’s js file.
For more information on this, please click below:
https://community.cloudflare.com/t/sucuri-has-flagged-as-a-malware-file/229587
Hope this helps the community, and also helps the developers of iThemes update their code to account for Cloudflare’s tool, “Bot Fight Mode.”
Update: (are we having fun yet?)
OK, so the Bot Fight Mode has nothing to do with the issue we first reported above. Confirmed with Cloudflare and our host, SiteGround.
We’re still experiencing issues with iThemes Security’s malware scanner. Results continue to show “clean” but still getting a “red dot.”
In fact, last night, we performed several manual scans and got some php errors (changed all the time without us doing anything to our website). So, we can safely assume that iThemes developers are racking their brains over this issue.
We’ll continue to wait for an update from iThemes. Zero support for a while. Let’s hope they’re OK.
Cheers!
Update:
Site Scanning errors continue. This is what we currently get:
Scan Results (Notice Red dot with “Clean” message): https://prnt.sc/yf9y1o
Raw Details: https://prnt.sc/yfafkvWhat’s going on iThemes Security? One other thing we noticed is that every time we perform a manual malware scan, the Source IP for performing the scan is our own IP. What? Shouldn’t the Source IP for the malware scan come from Sucuri or Google?
Got fix? The minions are waiting 🙂
PS: In lieu of fixing the above, please bring back the legacy malware scanner method. Much cleaner and nicer UI (using Google ain’t good enough)
Reproduces instantly.
Looks like a server side issue.
Scan results may vary due to results caching (transient in the wp_options table).Results caching probably implemented to balance the load.
Seems like errors aren’t cached. So after one or more (manual) site scan failure(s) at some point there is nothing returned. This is because the site scan result stored in the transient in the database is empty.
Manually deleting the transient in the database results in the error being displayed again upon the next site scan.The “Exceeded rate limit” message points in the direction of some sort of quotum limitation.
Probably nothing we can do. iThemes will need to dig in.
Update:
We received an update from iThemes Support indicating that the above issue is caused by an API issue with Google. They have no time estimate for when Google will update their API.
Stay tuned.
Cheers!
Thank you for keeping us posted 😉
- The topic ‘Multiple Site Scan Errors’ is closed to new replies.