yorman
Forum Replies Created
-
Unless the website is using the Sucuri Firewall, there is nothing in the plugin’s code that can selectively block any HTTP request. The plugin does not do any sort of attack recognition so whatever is blocking the bot that you wrote is not part of the code that I wrote. However, the entire code is open-source [1] feel free to check it and if you find something don’t hesitate to ask more questions.
The malware scanner is running automatically since a couple of versions ago.
There is no need to have an option to execute it as the plugin does that by itself via a scheduled task that runs approximately every 24 hours. The data is now part of the main page of the plugin’s dashboard, divided into three different sections, one part was merged with the WordPress integrity tool, the second part was merged with the audit logs and the third part was put on a column on the side of the audit logs.
SiteCheck error: Unable to properly scan your site. Site returning error: HTTP/1.1 503 Service Unavailable
This error message refers to the inability of the remote scanner (aka. SiteCheck [1]) to read the content of your website for reasons that are out of my understanding as there could be millions of things that could explain this. The only thing that I can say for sure is, the API service tried to connect to your website and instead of a successful response it obtained a “503 Service Unavailable” error message.
Please communicate with your hosting provider to find the solution.
The same way the error suddenly appeared, the same way it will disappear when your hosting provider tells you how to fix whatever is broke in your web server. This is not a problem with the plugin nor the API service, if I have to guess, your hosting provider probably blocked the access to the IP address associated to the server that is hosting the SiteCheck service, but that’s just an speculation.
Marking as resolved, feel free to ask for more information.
WordPress doesn’t provides a proper “uninstall” mechanism.
That’s why I decided to force the plugin to delete the data associated to it during the deactivation, which seems to be the only thing that resembles the uninstallation process. I have received more complains from people asking why was the plugin leaving traces of its data in the website after the deactivation than from people asking to keep the data intact.
The good news are, the plugin stores all its data in flat files which are easier to restore than information in the database. You can easily obtain a copy of these files from the daily backups that all popular hosting providers offer generate. Regarding the audit logs, you can request a copy of your API key via email and after the re-activation of the plugin the API will send the logs that were previously recorded. At the end you are losing no data.
I will move this to our internal issue tracker and let my project manager decide.
A 105 Error is not an application-level error, it’s a server error.
The problem must be related to the use of a PHP built-in method used to reverse the hosting IP address, this is necessary to detect if your website is behind a firewall or not, and so in conjunction with a misconfiguration in your hosting account, the execution of that function is throwing the DNS resolution error.
Please keep the plugin disabled, I will fix the bug once I can reproduce it.
A
105 Erroris a DNS resolution error [1] and is one of the most commonly faced errors by a lot of users everyday who are using Webkit browsers like Safari or Google Chrome. It basically means that when you enter the URL of the website and hit enter, it tries to resolve the IP address of the website using a protocol called DNS (Domain Name System). If chrome is unable to reach the DNS server, the name resolution fails and you get the error 105.This is a server issue that you have to address with your hosting provider.
If you are completely sure that keeping the plugin disabled fixes the problem, then please keep it that way until we can replicate the bug and release an update with the fix. However, I am confident that this is a server issue more than a problem with the plugin’s code.
[1] https://en.wikipedia.org/wiki/Talk%3AList_of_HTTP_status_codes#Error_105
The plugin in itself does not performs any type of server-side scanning that can be used to detect cryptocurrency or any other type of malicious code. The plugin only monitors the changes in the code, the events triggered by WordPress, and suspicious code served via HTTP, anything else is out of the scope of this project.
However, Sucuri offers a premium service as part of the Security Platform [1] that includes server-side comprehensive and thorough intelligence. Unfortunately, I am not a sales guy so I cannot provide enough information to answer your question. Feel free to contact one of my co-workers in the sales team via our chat [2] they will be able to answer all your questions with more details.
[1] https://sucuri.net/website-security-platform/
[2] https://sucuri.net/ (bottom-right corner of the page)As an alternative, you could include the security headers directly from a PHP script, however, because this requires the modification of one of the core WordPress files it may not be the best solution but can achieve the same results:
<?php header('X-Frame-Options: SAMEORIGIN'); header('X-XSS-Protection: 1; mode=block'); header('X-Content-Type-Options: nosniff'); ?>Adding this piece of code at the top of the main
index.phpfile works.Does anyone know why the messages are still appearing?
There could be to answers to your question.
One is Cache and the other is missing Headers module.
How Does The Sucuri Cache Works?
There are two explicit and one implicit cache mechanism running in place during the execution of the web malware scanner. The first one is in your local web server, controlled by the plugin, and it usually expires every 20 minutes, you can reset this from the “Data Storage” panel located in the plugin’s general settings page, the file is called “sucuri-sitecheck.php”.
The second cache is controlled by SiteCheck, the server that the plugin uses to scan your website. The cache here expires every 48 hours unless someone requests a fresh scan before the automatic flush is executed. The problem is that requesting a fresh scan doesn’t flush the cache, it just skips it, the cache will still be served until the 48 hours period ends. In order to make the plugin show the fresh scan results every time it would require a modification in the code that would make your website admin interface load slow, this is why the cache is important, to prevent this slowness.
The third cache is implicit, and is part of another system that has little relation with the whole thing. This cache is controlled by the Sucuri Firewall. When your server sends a HTTP request to the SiteCheck API the firewall caches the request in one of our datacenters to serve the same request faster in subsequent attempts to request the same resource.
What About The Apache Headers Module?
The rules that you included in your access control file are wrapped around a condition that checks if the Apache headers module is enabled, otherwise the instructions inside that block are ignored. If you can verify that the module exists and is enabled then we can assume that the cache is the culprit, otherwise I suggest you to communicate with your hosting provider to ask for alternatives to include those headers. You can also include them using PHP but it requires the modification of one of the WordPress core files so I prefer not to teach you how to do it.
The cache will be flushed after 48 hours, you can ignore the warnings for now.
The plugin checks the integrity of the WordPress installation using data that comes from a public API service controlled by Automattic, the company who develops WordPress. In this case the language files are okay, it’s just that the data that is coming from the API is incorrect, and we [Sucuri] have no control over this.
However, because people keep reporting these warnings, I have decided to include the language files in the list of extensions that are ignored during a scan [1]. The development version of the code already contains this patch [2] so feel free to install it if you want to have an immediate solution or wait for the release of the update in a couple of weeks.
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/b88fd35
[2] https://github.com/cixtor/sucuri-wordpress-pluginHello @wpjcs — the code that powers the WordPress Integrity tool has no relationship with the code that powers the Malware Scanner, even if the information is printed in the same part of the interface, they are distinctively separated code-wise.
For the issue mentioned in this thread (the cache problems with the Malware Scanner — SiteCheck), we already found that requesting a scan while skipping the remote cache mechanism from the API works, and as mentioned in my previous message I will add a button to clear this cache if necessary when people notice out-of-sync data, this will be released with the next version of the plugin.
As for the warnings in the WordPress Integrity tools, these files are resources that according to your WordPress version should be in your project but aren’t. The plugin considers this suspicious and so proceeds to mark them with a red flag. If you think there is nothing wrong with your installation then select all the files and mark them as fixed using the dropdown at the bottom of the table. Alternatively, you can select them and choose the option “restore” which will request the download of the original code from the official WordPress repositories.
I already modified this piece of code in the development version of the plugin [1] to basically ignore the warnings when the resources are clearly language files, they are usually harmless and apparently associated with a bug that WordPress has to fix, but I have no power over their development process so I cannot force them to work on a fix immediately, I decided to take action in the code that I maintain.
Feel free to install the development version of the plugin [2] or wait until the next update.
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/b88fd35
[2] https://github.com/cixtor/sucuri-wordpress-plugin@wpjcs — yes you can revert the changes.
I will add a button in the next version of the plugin to execute this HTTP request without the cache in case that anyone else have the same problem. That way, they will not need to modify the source of the plugin to get the updated data. Thank you for the bug report.
@ale5000 — thank you for the notice.
I don’t have control over the development process in the SiteCheck project, so there is not much I can do besides filling an internal bug report (which I already did when you posted this ticket a week ago). I will talk to them again today, maybe the bug was already patched (internally) but hasn’t been pushed live, and the reasons for this are unknown to me, some times they are working on something else and need to finish the QA testing before executing a deployment.
Please ignore the warning for now, you already included that security header and that is enough. I will try to get the patch pushed live in the next couple of weeks. Thank you for your patience.
Hello @wpjcs — yes the problem may be caused by an additional cache somewhere in the middle of the two nodes (plugin and API service). To be honest I don’t know how SiteCheck caches the results of the scans, my co-worker have explained this to me a couple of times in the past, but with so many things in my head I easily forget.
I remember a case a couple of weeks ago where a customer was reporting exactly the same thing that you are seeing in your website. I barely remember the solution, but at this moment I am unable to confirm if it works or not, so please give it a try just in case but feel free to come back to this ticket for more information.
Use your favorite (S)FTP client to connect to your web server, or use the file manager app available in your hosting admin panel. Navigate to the directory where the plugin’ source files are located [1] and open this file [2] then jump to line 126 and change this piece of code [3] to this [4]. Upload the modified file (or save the changes if you are using the cPanel code editor), delete the cache file once again [5] and reload the plugin’s dashboard.
These changes will force the plugin to execute a fresh scan, without the API service cache, every time the cache in the local server expires. This is, every 20 minutes your website will request a fresh scan from SiteCheck.
Let me know if it works.
[1]
/wp-content/plugins/sucuri-scanner/src/
[2]/wp-content/plugins/sucuri-scanner/src/sitecheck.lib.php
[3]$results = self::runMalwareScan();
[4]$results = self::runMalwareScan(true);
[5]/wp-content/uploads/sucuri/sucuri-sitecheck.php