• Resolved Jo Sprague

    (@josiahsprague)


    We’ve had an issue with Sucuri settings being completely reset to the defaults with no action on our part. This causes problems with our site performance and causes us to get a flood of noisy email alerts from Sucuri. I believe the problem may be related to the change that stores settings in a text file rather than the database. We’ve got two servers behind a load balancer, so that may be causing some problems with the way that Sucuri checks for the settings file. There are two copies of that file, one on each server. They’re usually in sync, but there could be a situation where one of the servers doesn’t have the updated file for a couple seconds. Both servers connect to the same database.

    Right now I’m just trying to collect some more information about what’s going on so we can prevent it from happening again. If I look in the /wp-content/uploads/sucuri directory, I’m seeing many copies of all of the files with a number appended on the end;

    -rw-rw-r--  1 www-data www-data    730 Jul 11 08:50 sucuri-settings.php
    -rw-rw-r--  1 www-data www-data    587 Jul  6 10:35 sucuri-settings.php1467877470
    -rw-rw-r--  1 www-data www-data    878 Jul  8 22:59 sucuri-settings.php1468136919
    -rw-rw-r--  1 www-data www-data    233 Jul 10 19:32 sucuri-settings.php1468180207
    -rw-rw-r--  1 www-data www-data    282 Jul 10 23:03 sucuri-settings.php1468223493

    There are 991 files in that directory, which doesn’t seem right. Do you have any ideas what is going on here? Where are all of these files with the number at the end coming from?

    https://wordpress.org/plugins/sucuri-scanner/

Viewing 4 replies - 1 through 4 (of 4 total)
  • It looks like our host has a service running that may be renaming files in the uploads directory with that postfix. I’ll see if they can add an exception for the uploads directory. Closing this for now. I’ll reopen it again later if that turns out to not be the issue.

    Here’s some more info about the issue in case other people experience something similar;

    Our host has a process that runs as a part of their built in security hardening that removes any .php files in the uploads directory since that’s a common attack vector. To resolve the issue, I just had to store the Sucuri settings somewhere other than the uploads directory, so I created the directory /absolute/path/to/wp/install/wp-content/plugins/sucuri-settings and added define('SUCURI_DATA_STORAGE','/absolute/path/to/wp/install/wp-content/plugins/sucuri-settings'); in my wp-config.php.

    Daniel, maybe in future versions of the plugin you could consider changing the default storage location for the settings php files to be in the plugins directory instead of uploads. The uploads directory may not be the most secure location even with the exit() lines for several reasons. For example; sometimes people copy and paste their upload directories via FTP expecting it to just be uploaded media and not to contain sensitive data.

    I wonder if you’d also be able to offer an option to store the settings in either the database or the filesystem, as I could imagine a use case where people prefer to continue storing their settings in the database.

    Plugin Author yorman

    (@yorman)

    Thanks for explaining this, I am sure it will be helpful to other users.

    Regarding your suggestion to add an option to force the plugin to keep using the database instead of the plain text file to manage its settings, I thought about this before the release of version 1.7.18; I prefer to keep enforcing the usage of the plain text file because the were important issues (mostly related with multisite installations) that couldn’t be easily fixed using the database. I added some information in the settings page explaining some things [1].

    However, you can hack your way around this simply creating the “sucuri-settings.php” file and removing the write permissions [4] the plugin will detect that it can not write in the file and will fallback to write the settings in the database. Alternatively, you can define a constant “SUCURI_SETTINGS_IN” with value “database” [2] which will have the same effect. I encourage you to keep using the plain text files as this guarantees that the automated tests that we have in our development process will catch all the bugs related with this, we do not (and will not write) tests assuming that someone is still using the database to store the settings.

    Feel free to install the development version of the code [3] or wait for the release of the next version of the plugin to be able to continue using the database as explained above.

    [1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/233854d
    [2] https://github.com/cixtor/sucuri-wordpress-plugin/commit/af46d6a
    [3] https://github.com/cixtor/sucuri-wordpress-plugin/archive/master.zip
    [4] chmod 444 sucuri-settings.php

    Using the other path works for us. I’m not sure if wp-content/uploads is the right default location for a settings file, as I mentioned above. You might want to consider making the default location wp-content/plugins/sucuri or something like that. It’s not a difficult issue for us to work around, but polluting the uploads directory, which is usually user-uploaded media files, with configuration and settings is probably a bad practice.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Plugin Settings Being Reset’ is closed to new replies.