Forum Replies Created

Viewing 15 replies - 466 through 480 (of 537 total)
  • According to the WPScan Vulnerability Database the iTSec plugin 4.3.11 release contains 6 KNOWN vulnerabilities.

    I think it’s time to upgrade both, the iTSec plugin AND WordPress …

    It will also fix your Database Backup issue.

    Seems to be a specific issue when you have enabled the Split File Scanning setting in the File Change Detection module.

    So as a workaround disable that.

    Anyway in the next release the File Change Detection scan engine will be completely rewritten (it’s already available in the Pro premium plugin).


    Compress everything into archive and check its hash sum. Dont do any changes after that.

    I think this needs a bit of clarification.

    Let’s assume we have a folder with 100 .php files.
    So we “Compress everything into archive”. What is the result ?

    a. A folder with 100 .php files and 1 archive file (100 + 1 = 101 files).
    b. A folder with only 1 archive file (100 – 100 + 1 = 1 file).

    Check changes using plugin. a WONDER – a lot of changes!

    Please specify what changes the iTSec plugin reports. Specify # Added, # Removed, # Changed files. Like:

    (a) 1 Added, 0 Removed, 0 Changed.
    (b) 1 Added, 100 Removed, 0 Changed.

    • This reply was modified 1 year, 10 months ago by nlpro.

    (I’ve tagged this post with modlook, which means a forum moderator will have a look at this).

    Would it be possible to get a decent translation of the last post added in Russian ?

    I’ve looked around on but I could not find a procedure for requesting a post translation. So I decided to do it this way. I’ve run the text from the post through Google translate but the resulting translation is not good enough to understand properly what the post is about.


    The 6.9.1 release includes a security fix:

    Security Fix: Fixed display of unescaped data on logs page

    For more info about all security fixes in the iTSec plugin visit the WPScan Vulnerability Database.


    Are you using Google Translate to translate Russian into English ?
    I’ve read several of your posts on this forum and with every post I find it very difficult to understand what you are saying.

    If not using Google Translate please try and add your post in English and Russian.

    I don’t speak or read Russian but maybe someone who does can then add a proper English translation.

    The first File Change Detection scan ever run on your site will always report ALL files as Added…

    This is because the first File Change Detection scan has nothing to compare with.

    A File Change Detection scan compares the current state of your site files with a file list which was stored in the MySQL database by the previous File Change Detection scan.

    Sometimes a site is made up out of so many files that due to MySQL database size limitation(s) the file list fails to be stored in the database (It’s a lot of data to handle in a single MySQL statement). This effectively results in every File Change Detection scan to produce the same result … (as if it is run for the first time).

    To identify this specific situation visit the Logs page and filter for File Change Detection entries. If there are multiple consecutive entries with only 1000s files Added (0 Removed, 0 Changed) then its likely you are hitting a MySQL database size limitation issue.

    Last but not least, once the File Change Detection module is enabled a scan can be triggered by anyone accessing your site.
    On every page request (frontend or backend) the iTSec plugin checks whether the current time is past the File Change Detection scheduled time, and if so a scan is automatically run.

    • This reply was modified 1 year, 10 months ago by nlpro.

    (No worries, happens all the time)

    Doesn’t responding to your topic qualify as a favor ?
    I guess not (in your perception). And that’s fine. We are all different.

    Does Softaculous install WordPress with the iTSec plugin included ?
    (Or perhaps it’s an installation option. I’m not familiar with Softaculous …)

    The line is specific for the iTSec plugin. Only when Softaculous installs WordPress with the iTSec plugin included (as a configurable install option or not) it would make sense to let the developers of Softaculous know about it.

    After giving my latest recommendation one last thought I realized that step 4 will take place on the new wp_itsec_logs table (I verified that in the plugin code).

    If the logs migration has NOT yet taken place that table does not yet exist.
    The logs table is still named wp_itsec_log
    So the scheduled logs cleaning task will fail … unless …
    we make a small temporary code change.

    So after step 3:

    – Make a backup copy of the wp-content/plugins/better-wp-security/core/lib/log.php file.

    – Edit the wp-content/plugins/better-wp-security/core/lib/log.php file and search for the following unique string: {$wpdb->base_prefix}itsec_logs

    – Replace that string with: {$wpdb->base_prefix}itsec_log (We are only removing a single character: s). Save the change.

    Step 4 will now be able to execute without failing.

    After step 4 is completed delete the changed log.php file and restore the backup copy we made.

    Continue with step 5.

    Considering the amount of websites you manage (>100) I aimed for a procedure which is as simple as possible. Unfortunately having to edit a plugin file complicates the procedure. But it’s a necessary step.
    You could make a master copy of the changed log.php file and copy that to the other envs. That limits the edit code part to only once 😉

    Good luck.

    The migration msg displayed when you access the Logs page for the first time after updating the plugin to the 6.9.0 release or later, is happening because iThemes also introduced a new logging system in the 6.9.0 release.

    The migration creates a new wp_itsec_logs table in your database and then converts and moves records from the old wp_itsec_log table to the new table. Once completed the old wp_itsec_log table is removed from the database.

    Unfortunately the migration of large datasets can have significant impact on the server. So it’s vital that the old wp_itsec_log only contains a small dataset before the migration starts. As you have seen, due to the plugin not properly hooking into WP-Cron the task scheduled for regularly cleaning the wp_itsec_log table is often not running. So instead of the expected 2 weeks dataset (or whatever is configured in the Global Settings module) there is often a larger dataset stored. Best you can do is fix the WP-Cron issue. Then wait for the plugin (cleanup task scheduled in WP-Cron) to truncate the data stored in the wp_itsec_log table.

    Once that is done you can access the Logs page (for the first time) and the migration will only take a few seconds without running the risk of negatively impacting server performance.

    And when all that is done, the email issue is still not solved …
    But we can continue with that after taking care of the WP-Cron issue.
    You’ll probably agree with me that it’s pretty important to get the plugin to properly hook into WP-Cron. It’s not just the log table which is not being truncated on a daily basis, there are another 2 daily tasks for truncating the tables that contain locks and lockouts … those are also currently not running.

    So my recommendation is to execute the 5 steps below first on an env where you know there is a too large dataset (use phpMyAdmin) AND you have not yet accessed the Logs page after updating the plugin to 6.9.0 or later release:

    1. Add the MANDATORY line to the wp-config.php file:

    define(‘ITSEC_USE_CRON’, true);

    2. After adding the line above to the wp-config.php file wait for at least a day (>24 hours).

    3. Then deactivate/activate the plugin.

    4. Wait for another day (Truncating the logs table is a daily task).

    5. Access the iTSec Logs page to start the log migration.

    • This reply was modified 1 year, 11 months ago by nlpro.
    • This reply was modified 1 year, 11 months ago by nlpro.
    • This reply was modified 1 year, 11 months ago by nlpro.

    Ok, that’s interesting.

    But I think there is an explanation for that. Could you check on those sites for how many days there are log entries in the Logs page ? Only check on a site where the iTSec plugin 6.9.2 release is installed/updated MORE than 2 weeks ago. Also make sure to click on the All Events link. Then navigate to the last page. At the bottom you’ll find the oldest log entry.

    If the plugin is properly hooking into WP-Cron the Logs page will show data for max 14 days. This is the default setting in the Global Settings module.
    However if the Logs page contains more than 2 weeks of data (again assuming the unchanged default here) then the plugin is not properly hooking into WP-Cron (despite File Change Detection scans being processed by WP-Cron). In that case, yes follow my recommendation anyway.

    I’ll wait for your feedback. Once we have established the plugin is properly hooking into WP-Cron (for all scheduled tasks) we can continue with the email.

    Let me start by saying I totally agree with you. But …

    According to the FAQ section in the readme.txt file:

    = Where can I get help if something goes wrong? =
    * Official support for this plugin is available for iThemes Security Pro customers. Our team of experts is ready to help.

    Free support may be available with the help of the community in the support forums (Note: this is community-provided support. iThemes does not monitor the support forums).

    Note the bold section at the end of the quote.

    So if you are looking for a statement from iThemes regarding GDPR compliance of the iTSec plugin IMHO it’s probably best to contact iThemes directly.

    It seems this bug was introduced in the 6.9.0 release. Weird noone else reported it yet …

    Please check in the Logs page whether the affected File Change Detection scan(s) are scheduled ones (probably).

    Simply click on the Show Details link and check the Url field value.

    Scheduled scan values are:

    – “WP-Cron Scheduled Task”
    – Any url that is not pointing to the admin-ajax.php file (that’s a manual scan).

    There is another issue with the plugin not hooking properly into WP-Cron so I expect you’ll probably see the second listed above as Url value. It’s basically the url that kicked off the scheduled scan. It can be a frontend url as well as a backend url.

    It seems the line below is MANDATORY in the wp-config.php file for the plugin to properly hook into WP-Cron:

    define(‘ITSEC_USE_CRON’, true);

    After adding it to the wp-config.php file wait for at least a day (24 hours) then deactivate/activate the plugin. That will make the plugin hook properly into WP-Cron. From that moment on you should see the first as Url value in the Logs page. It’s not going to fix the email issue, but you want WP-Cron to run these type of tasks.

    Let me know whether your scans are scheduled ones and we can look for a temp fix for the email issue.

    • This reply was modified 1 year, 11 months ago by nlpro.

    The iTSec plugin does not inject stuff into other files.

    Assuming default settings, when you receive 3 Site Lockout notifications within 7 days for the same IP (I guess we are talking emails here) that IP will be banned (permanently). Which means the iTSec plugin will add some lines to the .htaccess file that will prevent the IP from being able to access the site. Normally this process should not interfere with normal operation of the site. Only the banned IP is affected.

    It certainly doesn’t affect any css.

    Simply add the line below to your wp-config.php file:

    define('ITSEC_USE_CRON', true);

    Wait for a little more than a day and then deactivate, activate the plugin. This should reset the plugin hooking into WP Cron.

    Setting ITSEC_USE_CRON to true in the wp-config.php file is MANDATORY for the plugin to properly hook into WP Cron. However it’s poorly documented.

    • This reply was modified 1 year, 11 months ago by nlpro.
Viewing 15 replies - 466 through 480 (of 537 total)