Forum Replies Created

Viewing 15 replies - 481 through 495 (of 544 total)
  • 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 WordPress.org support forums (Note: this is community-provided support. iThemes does not monitor the WordPress.org 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.

    Why ?

    And why only for Site Lockouts Notifications ?

    There is a comment from development in the wp_mail() method:

    If we don’t have an email from the input headers default to wordpress@$sitename.
    Some hosts will block outgoing mail from this address if it doesn’t exist but
    there’s no easy alternative. Defaulting to admin_email might appear to be another
    option but some hosts may refuse to relay mail from an unknown domain.

    Anyway the plugin does not facilitate changing the email address that Site Lockouts Notifications are sent from in the Notification Center. It would probably require custom code. IMHO the only option would be to hook into the wp_mail filter.

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

    Ok, probably a css conflict with another plugin. Start deactivating plugins one by one, and then checking whether the issue persists or not.

    Enabling the SSL module only ensures that your site cannot be accessed in non SSL mode.

    It does so by adding the following line to the wp-config.php file:

    define( 'FORCE_SSL_ADMIN', true ); // Redirect All HTTP Page Requests to HTTPS - Security > Settings > Secure Socket Layers (SSL) > SSL for Dashboard

    As a return favor could you please answer the following question:

    Does your wp-config.php file contain the following line:

    define(‘ITSEC_USE_CRON’, true);

    It’s highly recommended but it is poorly documented. As a result probably nobody is using it. You can read all about it in this topic.

    Gary,

    Try and add the following line to the wp-config.php file (if it does not already exist):

    define('ITSEC_USE_CRON', true);

    It may take some days before seeing any results. So be patient 😉

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

    Below a bit of history about the scheduling constants used by the iTSec plugin in the wp-config.php file. It will probably help understand my reasoning:

    Old scheduling framework (pre 6.8.0 release):
    —————————————————–
    Default: page-load

    Alternative: cron
    Configured separately per module by defining the following constants in the wp-config.php file (and setting them to a true value):

    File Change Detection: ITSEC_FILE_CHECK_CRON
    Database Backup : ITSEC_BACKUP_CRON

    Not defining these constants was equal to setting them to false.

    New scheduling framework (6.8.0 release and newer):
    ———————————————————–
    Default: cron
    The former ITSEC_FILE_CHECK_CRON and ITSEC_BACKUP_CRON constants are deprecated.

    A single constant is used (ITSEC_USE_CRON) which IMHO should only be used to prohibit the iTSec plugin to use the default cron system for scheduling module tasks.
    Since cron is the default scheduling system it makes sense to assume that NOT defining the ITSEC_USE_CRON constant is equal to ITSEC_USE_CRON=true.
    But as I explained in my previous post that does not seem to be the case in the iTSec plugin 6.9.2 release. IMHO this is a bug in the itsec_cron_test callback.

    Alternative: page-load

    I think it’s also important to mention that you should always try to use cron for any scheduling activities. There are several obvious benefits to using cron to handle scheduled tasks as opposed to on page-load. iThemes rightfully switched to using cron by default in the iTSec plugin.

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

    The itsec_cron_test task is also a single event task which receives the scheduled execution time as an argument.
    If the result of the most recent itsec cron test event is negative the plugin changes the internal settings ‘use_cron’ to false and ‘cron_status’ to 0.

    		Default		Cron	No Cron
    		--------	-----	--------
    use_cron	true		true	false
    cron_status	-1		1	0

    (Where cron_status -1 is undetermined, 1 is available and 0 is unavailable).

    And this is exactly what I see happening. So why ?

    It turns out that in the itsec_cron_test callback the following code is executed:

    // Disable cron if the user hasn't set the use cron constant to true.
    if ( ( ! defined( 'ITSEC_USE_CRON' ) || ! ITSEC_USE_CRON ) && ITSEC_Lib::use_cron() ) {
    	ITSEC_Modules::set_setting( 'global', 'use_cron', false );
    }
    
    ITSEC_Modules::set_setting( 'global', 'cron_status', 0 );

    Notice the comment which says that cron should be disabled when the user has NOT set the ITSEC_USE_CRON constant to true.
    The condition that follows says: disable cron when the ITSEC_USE_CRON constant is not defined OR when it is set to false.

    Earlier we saw in the changelog that cron is now the default scheduling mechanism.
    (Which to me implicates that not defining the ITSEC_USE_CRON constant is equal to ITSEC_USE_CRON = true).
    Also the default value of the internal ‘use_cron’ setting is true …
    But the condition in the itsec_cron_test callback says disable cron when the ITSEC_USE_CRON constant is not defined. Clearly there is a contradiction here.

    So to fix this issue (or prevent it from happening) simply add the line below to your wp-config.php file:

    define('ITSEC_USE_CRON', true);

    Even though it is the default (preferred) scheduling system, if you want the iTSec
    plugin to KEEP using cron you HAVE to add the line above to your wp-config.php file.
    Also keep in mind, after adding the above line to the wp-config.php file, it may take a day for the next itsec_cron_test task to kickoff and correct the situation.

    Please note the above recommendation is for the 6.9.2 release only.
    If anything changes in a new release I’ll try and update this topic.

    kot41

    If you prefer not to be notified by email of any follow-up replies please unsubscribe from this topic.

    Ok, that’s great. However …

    Remember I mentioned something about a quirck in the plugin hooking into WP Cron ?

    I was able to identify the cause and find a simple (non code) solution as well.
    Before posting an explanation I think it is usefull to read 2 relevant quotes from the 6.8.0 changelog:

    • New Feature: Introduces a scheduling framework for handling events. Cron is now used by default, and will switch to using an alternate scheduling system if it detects an error. To disable this detection set ITSEC_DISABLE_CRON_TEST in your wp-config.php file.
    • Important: The ITSEC_FILE_CHECK_CRON and ITSEC_BACKUP_CRON constants have been deprecated. Use ITSEC_USE_CRON instead.

    The important parts from these 2 Changelog entries are ‘Cron is now used by default‘ (which means it is the preferred method of the iTSec plugin for scheduling tasks/events) and ‘Use ITSEC_USE_CRON instead‘.

    So when the ITSEC_USE_CRON constant is not defined (at all) or defined and set to true (in the wp-config.php file) the iTSec plugin will use the WP Cron system for scheduling tasks/events. It’s important to note that NOT defining the constant seems to be equal to defining it and setting it to true (do note this is my personal opinion based on the available documentation so keep in mind I could be wrong).

    Ok, so initially the iTSec plugin hooking into WP Cron seems to work fine without setting any related constant. But I noticed that after a short while the plugin stops hooking into WP Cron. The tasks scheduled by the iTSec plugin in WP Cron mysteriously disappear. Below is a list of the iTsec cron tasks I noticed initially:

    Name			Schedule	Arguments
    itsec_cron_test		False		1524611447
    itsec_cron		Daily		file-change
    itsec_cron		Daily		clear-locks
    itsec_cron		itsec-backup	backup
    itsec_cron		Daily		purge-lockouts
    itsec_cron		Daily		purge-log-entries
    itsec_purge_logs*	Daily		

    *This is a leftover from an earlier iTSec plugin release which iThemes forgot to cleanup … Add the following line to your active theme functions.php file to get rid of it:

    wp_clear_scheduled_hook( 'itsec_purge_logs' );

    As you can see iThemes switched to a more abstract scheduling system where all the tasks are named identically (itsec_cron) but the arguments passed to the cron task determines which task is to be executed.

    Notice there is 1 task that has a different name: itsec_cron_test.
    It seems iThemes includes this task to check whether the WP Cron system is functioning properly.

    Stay tuned, this post is to be continued …

    • This reply was modified 1 year, 11 months ago by nlpro.
    • This reply was modified 1 year, 11 months ago by nlpro.
Viewing 15 replies - 481 through 495 (of 544 total)