yorman

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/

@adaptablewebsites — people can still authenticate via XMLRPC [1]

[1] https://blog.sucuri.net/2015/10/brute-force-amplification-attacks-against-wordpress-xmlrpc.html

This is the code that is generating that message [1] as you can see, it checks if the global PHP variable $_POST is present and not empty (which only happens when you send a HTTP request using the POST method) then proceeds to check if the “sucuriscan_page_nonce” parameter is present in the request, it fails if the parameter is not present or if the value differs from the expected value to protect the forms against CSRF attacks.

When you click the links in the menu, you are sending a GET request to the server so this code will not execute, it only runs when you submit data via a form. Considering this, there is only one reason to justify the appearance of that message: another plugin or theme is pushing data into the global POST variable even when the request is via GET.

Compare the setup of one of the websites where the plugin works with the setup in this website where the plugin is showing that message. Any difference, including not only active but also installed plugins, themes and widgets is relevant. Make sure that they are configured the same way, then test again, I am pretty sure that the problem is in one of the plugins/themes that you have installed.

Alternatively, but this is very rare, your web server may be misconfigured and is duplicating the data from the GET request into other global variables like REQUEST which is also taken in consideration by POST, in this case you will have to communicate with your hosting provider to fix the issue.

Marking as resolved for now, feel free to re-open if you need more information.

[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/b1e8647/src/interface.lib.php#L240-L263

Although this message comes from the Sucuri plugin, I believe this ticket should have been posted in this other forum [1] where the BackWPup developers can explain the meaning of these changes.

As far as I know, the vendor directory is used in PHP projects as the default location to store 3rd-party dependencies, you can see them all here [2] including Guzzle which is — as their official repository says — an extensible PHP HTTP client [3]. The warning message says that multiple files associated with the “backwpup” plugin have been modified and it seems that it happened after an update, however, the original poster says that they did not update anything, which makes me think that either this plugin has an auto-update feature or someone else got into the server and modified the files with a different process outside of WordPress.

Due to performance restrictions with many hosting providers, the Sucuri plugin cannot display the details of the changes when they are detected, hopefully you can resolve most of the issues by restoring the affected files either from the WordPress integrity panel or from the post-hack page.

Marking as resolved, feel free to re-open if you need more information.

[1] https://wordpress.org/support/plugin/backwpup
[2] https://github.com/wp-plugins/backwpup/tree/master/vendor
[3] https://github.com/guzzle/guzzle

Usefulness of this enhancement though I think would have greater potential if it handled the GitHub API’s output natively.

Sure, why not. Considering that this feature will not be used by many people, I’ve decided to support GitHub repositories exclusively rather than open this option to random URLs, here is the commit [1] I guess this will also be useful for people who want to check their installation against the alpha version of WordPress [2].

WARNING! Everything related to this new feature works as expected. However, if you enable the “Diff Utility” from the scanner panel in the plugin’ settings page you will notice some problems. Here is why:

With the diff utility enabled, you can click the files in the integrity panel and the plugin will display a popup with the differences between the file in your WordPress installation and the file in API. To do this, the plugin downloads a copy of the selected file in the temporary partition of your server, then uses the Unix diff command to compare these two files. This command doesn’t knows how to understand certain white spaces, so the plugin will report that there are no differences between those two files even when their checksums are different. Below is an example:

XMLRPC.php by WordPress

0830  73732d49 58522e70 68702729 3b0a696e  |ss-IXR.php');.in|
0840  636c7564 655f6f6e 63652841 42535041  |clude_once(ABSPA|
0850  5448202e 20575049 4e43202e 20272f63  |TH . WPINC . '/c|
0860  6c617373 2d77702d 786d6c72 70632d73  |lass-wp-xmlrpc-s|
0870  65727665 722e7068 7027293b 200a0a2f  |erver.php'); ../|

XMLRPC.php by ProjectNami

0830  73732d49 58522e70 68702729 3b0a696e  |ss-IXR.php');.in|
0840  636c7564 655f6f6e 63652841 42535041  |clude_once(ABSPA|
0850  5448202e 20575049 4e43202e 20272f63  |TH . WPINC . '/c|
0860  6c617373 2d77702d 786d6c72 70632d73  |lass-wp-xmlrpc-s|
0870  65727665 722e7068 7027293b 0a0a2f2a  |erver.php');../*|

Notice how the code provided by WordPress has an extra white space right after the semi-colon at the end of the inclusion of “class-wp-xmlrpc-server.php” while the code provided by ProjectNami is clean. These changes are difficult to catch, so while the plugin will correctly flag this file as modified, the diff utility will print an error message saying “there are no differences between these two files”.

As in my previous comment, feel free to install the development version of the plugin from here [2] or wait until the public release in a couple of weeks. Enjoy it!

[1] https://github.com/Sucuri/sucuri-wordpress-plugin/pull/40/commits/c2f005e
[2] https://github.com/cixtor/sucuri-wordpress-plugin/archive/master.zip

Thank you for considering the Sucuri plugin in your tests.

Performance is something that we take seriously in all our products. We are constantly testing and improving our code to make sure that it meets our own requirements (because we use them in our own websites) as well as the requirements of our biggest clients, clients with websites that report thousands of hits per day.

I can assure you that the plugin will work well enough in a server with hundreds of website. This, of course, depends on how this web server has been configured and how the resources are shared among all the sites. I suggest you to install the plugin in groups of five websites, test them for at least a day or two, make sure that everything works as you expect, then keep installing it in the other websites, five by five.

Here are a few things that you should consider:

1. The API Service

The core feature of the plugin, the event monitor, uses a remote API service to securely store the data, if a hacker breaks into your website they will not be able to delete their fingerprints because the logs are in our own servers. This is good, but it has a disadvantage which is that your website, being written in PHP, has to lock the interpreter every time the plugin sends data to the API.

2. The Queue System

We have implemented multiple instructions in the code to make the monitoring of suspicious events as fast as possible. The current version of the code waits a maximum of 5 seconds to communicate with the API, in the event of a timeout the plugin stores the events in a flat file and tries to send it to the API again in 24 hours using a scheduled task. Today we upgraded our hardware to make the API service faster, and the next version of the code 1.8.8 will reduce the latency of the HTTP requests down to 0.5 seconds which signifies a 10x improvement.

3. The Database Relationship

The plugin does not touches the database at all. We use flat files to store the settings, the security logs and temporary data. This has its advantages as well as its disadvantages. For example, in a regular installation of WordPress the database engined is configured to use MyISAM by default which locks the tables during writes, for a plugin that needs to work fast this is a huge disadvantage, that is why we do not use the database to store our data, also, using flat files makes it easy for everyone to get rid of the plugin and its associated data very easily, during the deactivation the plugin leaves no traces of data in the website.

4. The Email Alerts

The plugin is extremely verbose, second to the hook and action mechanism that powers many parts of WordPress. Because of this, and considering that you have the intension to monitor many websites at once, you will receive a significant amount of mails reporting events that the plugin intercepts on each website. You have to configure the plugin to only send notifications about important events rather than all of them, and you have to do this for every website. Unfortunately, the default settings for the email alerts are designed for a single website, for a web agency with tens of site this will be an overwhelming experience. Please be sure to configure the plugin to meet your own needs.

5. The File Scanner

Depending on how your web server is configured and how the +100 websites share the resources of the machine, you will need to configure the plugin to skip any directory that is not part of the website where the plugin was installed. This is very important, if the default settings are left as they are the plugin will try to read every single directory and subdirectory in the document root until either the maximum execution time or the memory limit are reached, or until the operation finishes itself.

Marking as resolved, feel free to re-open if you need more information.

@verityr — I hope you have resolved the problem with the malicious code that your hosting provider was detecting in your website. I am marking this ticket as resolved, but do not hesitate to create a new one if you have questions related to the functionality of the Sucuri plugin.