• Resolved garrettlynch

    (@garrettlynch)


    Using the wordpress plugin however getting “SUCURI: SiteCheck error: Unable to properly scan your site. Site returning error (40x): HTTP/1.1 403 OK” with newest update (version 1.8.8). Did not occur before and no new plugins on site. How is this resolved?

Viewing 8 replies - 1 through 8 (of 8 total)
  • The message comes directly from SiteCheck and it appears when your server blocks the HTTP request that the remote scanner sends to your website to search for malware. I have seen this with JetPack and some hosting providers, but it is a rare case that cannot be fixed from the plugin because it is not really an error in the code, it simply means that something in your website is blocking the malware scanner.

    Make sure that these IPs are whitelisted:

    • sitecheck.sucuri.net 192.124.249.7
    • sitecheck2.sucuri.net 173.255.233.124
    • sitecheck3.sucuri.net 162.216.19.183

    If this doesn’t works, use this instead — https://sitecheck.sucuri.net/

    I saw on a forum post somewhere that whitelisting sucuri’s ip should resolve this, unfortunately the ip mentioned was an old one (192.155.94.43). I’ve now added:

    allow from 192.124.249.7
    allow from 173.255.233.124
    allow from 162.216.19.183

    to my .htaccess but no change – or perhaps I’m misunderstanding where you mean to whitelisting these. Can you give more detail please. Thanks.

    I could give you more details, but I don’t know what is inside your website or hosting account that is be blocking the requests, I just know that SiteCheck is getting a “403 Forbidden” status code when it sends a request to your website.

    If you are using a firewall, whitelist the IPs in the firewall. If your web server has a security module, whitelist the IPs in the security module. If your website has another security plugin, whitelist the IPs in that plugin. Maybe it’s your hosting provider the one applying the block rather than your website, talk to them and ask them for assistance, they have access to your server and the logs to know why the requests are being block. Once you have made the respective changes, verify that SiteCheck works using this link [1] changing “DOMAIN” with the URL of your website.

    [1] https://sitecheck.sucuri.net/results/DOMAIN

    Thank’s for your help on this. There’s no firewall. I deactivated all wp plugins and security modules in cpanel, contacted my host and they flushed any potential blocks – no change. Sitecheck works just fine.

    Out of curiosity I just swapped back to Securi wp plugin 1.8.6 and the 403 error disappeared. I do believe you that this is an error caused Securi’s server side but what if the error isn’t actually occurring and that displayed alert is being triggered as a result of a malformed clause in some new code in the plugin? – it’s a possibility.

    There were several changes between versions 1.8.6 and 1.8.8 associated to the code that is communicating with SiteCheck to scan your website, but nothing that could cause a consistent 40x error. The plugin basically sends a GET request like this [1] decodes the response and reports back whatever SiteCheck found.

    Give it a try, just change “example.com” with your domain name. If you can see the same error message in the JSON object then we will be sure that the problem is in the API, I will contact my colleagues and ask them to fix the error. However, if the error does not appears in the JSON object, we could consider that the problem is actually with the cache of the plugin, it caches the results from the API for 20 minutes and can be flushed form the settings page (from the data storage panel).

    If you want, you can send me the domain name of your website to my corporate email at [removed] (email removed to avoid spam) and I will investigate the issue in my own server. Then will report back with a solution.

    [1] https://sitecheck.sucuri.net/?fromwp=2&json=1&scan=example.com

    The json looks clean.

    >we could consider that the problem is actually with the
    >cache of the plugin, it caches the results from the API for 20 minutes

    This makes sense and I did see a mention of caching of the plugin on a forum but couldn’t figure out where the clear cache they referred to is – which of the files under datastorage is the cache that should be deleted? Did a scan with 1.8.6 – still no errors. Swapped out for 1.8.8 again and did a scan (well after 20 minutes had elapsed) – now no errors. A bit mystified but seems to work now 🙂

    Awesome! Thank you for testing and verifying that the problem was with the cache.

    For future references, the plugin stores the logs, settings, and cache in flat files in this directory [1] they are mostly JSON-encoded objects and can be safely deleted at any time without causing a disruption, even the API key can be recovered in the event of an accidental deletion of the settings file.

    The cache for SiteCheck is stored here [2][3]; if the data in the cache has not expired the plugin will use it to display the information the dashboard, this makes the page load fast. When the cache expires after 20 minutes, the plugin requests a new scan to SiteCheck. Notice that SiteCheck has an independent cache system which stores the data for 48 hours, this can be flushed clicking a button at the bottom of the results page.

    [1] /wp-content/uploads/sucuri/
    [2] /wp-content/uploads/sucuri/sucuri-sitecheck.php
    [3] http://i.imgur.com/neVcCYi.png

    No problem, many thanks for your help and continued success with the plugin – its very useful!

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘403 error’ is closed to new replies.