DrProtocols

Just for additional information – I have noticed other topic(s) where it is mentioned that the problem (or a similar problem) with false positives was caused because:

We are seeing malware in the wild that is using a pattern with a str_replace followed by a function call where the function is a variable name. We added detection for this but it turns out that a few plugin authors do a str_replace and then a lambda call (anon function assigned to variable) on the same line. Who knew!

Here is one example of what is causing a file to be stated as having been installed by a hacker to perform malicious activity:

$self = get_called_class();
		return new $self($options);

where the particular function within which this appears is an init or factory type function and needs to determine the actual class context within which it is being used to be able to instantiate an object of the required class. There is no str_replace() type function usage.

If you could enhance your detection algorithm to look for more specific threat signatures that would likely go a long way to avoiding these sort of false positives.

Perhaps your initial option when signalling a potential issue like this would be to tell your users to click a button to send the apparently offending file to you and you can do triage since you know what you are looking for whereas the average user probably doesn’t have a clue. Otherwise users are left scrabbling to try and get advice from plugin or theme authors whereas it is WordFence that is raising the flag so WordFence authors should be the first line investigators – I’m sure this would be a good incentive to reduce the false positive rate ??

Can you please advise what plans you have to reduce the false positive rates for this kind of threat detection, thanks.

Making a simple wp_remote_get() to wp-admin/admin-ajax.php is a useful way to test whether actual http loopback is working under the hosting (with no action I believe it returns a 0 or perhaps -1 on older WP versions). If loopbacks are working then that usually works even if there is some maintenance mode type plugin or theme functionality blocking the front-end type access and it _shouldn’t_ be interfered with by caching of any sort AFAIK?

Then in addition to that to check wp-cron.php in particular perhaps a similar loopback attempt to that file with perhaps the provision of a new query string that indicates a wp-cron.php loopback test so that unlike the standard access a response is returned in the same manner as from admin-ajax.php and then the response can be tested for any any anomaly (or a response timeout) indicates some possible interference.

Common sources of interference are: maintenance mode plugins that simply block access and almost universally they have no way of “whitelisting” anything to allow access to; or various type of http based security; or any number of other things – but anything other than an expected response should be taken as “requires investigation”.

Also checking for simple thing like cron being disabled in wp-config.php if that isn’t done already as it is not uncommon for a host to set that without their Customer being aware. If this is set it may of course be because someone is using a server cron but that is hard to tell – so maybe if this was disabled then a string warning that unless you know why it is disabled (i.e., you did it and you know the consequences) then it needs investigation.

If the alternate cron is enabled then _usually_ that indicates things will work because someone has actually had to go to the trouble of enabling it so they had a reason and they will have checked that it works – and of course that isn’t so easy to check whether it is actually working programmatically.

Provided the access to wp-cron.php gets through then usually the actual execution is ok.

Could mean your server has barfed on one of the tests as I don’t think you get any results until all the tests have been run. Check in your PHP error log file for any coincident warnings or errors.

In that case it probably is your language issue as per a quote from a make.www.ads-software.com topic on this:

“Localised (non-english) installs are currently not receiving Background Updates.

3.7.1 Background updates will be enabled for localised builds shortly, there’s just been some unexpected www.ads-software.com infrastructure work that needs to happen first.

They’ll be enabled in the near future (next few days for sure) but in the meantime you can either update manually, or, if you’re not being affected by any of the bugs fixed in it (there’s no security fixes in this release) simply wait a few extra days for it to kick in.”

This was posted 31st October so I guess whether you wait for the auto update that should happen in the next few days or take the update manually depends on whether there is actually anything in the update you actually need.

I believe the check is set to run twice a day at 7am/7pm local time (or whenever the WordPress cron is triggered after that due time) but it may be there is some additional “throttling” that further controls when any individual site might get the update so as not cause an avalanche of update requests – I’m sure one of the experts will confirm/deny/explain if that is or isn’t the case ??

But your WordPress cron _must_ be functional otherwise the check simply will not be executed in the first place – so you should verify that your scheduled tasks are executing as required, this is something that the plugin does not currently test and verify.

If you are not sure you might use something like the WP Crontrol plugin that will let you look at the WordPress cron table and see what tasks are queued, when is their next scheduled run time (so you can check for stuck/overdue tasks) and do other cron related stuff.

I am a customer of iThemes and I have experience of WordPress and using various plugins as well as maintaining website for various clients on which I use iThemes products – does that somehow invalidate what I have said? You can take it or leave it as you like but it’s all just based on personal experience and getting on and getting things done. If you (as in the general hosting customer world) are happy to give your money to a host and be happy with whatever they happen to feel like giving you then fine, personally I prefer to hold them to account and if they are shortchanging me without telling me then I’m happy to move elsewhere where I get a better product and better service – you are of course entitled to your own view ??

Ah, well that’s changing the goalposts a bit then. Looking at the information from iThemes it does say that the fix for cron is for a very specific problem with the loopbacks. Probably if you have no other indication that loopbacks are not working (or you have actual positive proof that they are) then that isn’t actually the specific problem you have and therefore you shouldn’t be making that change.

There are other reasons why scheduling can fail (for a task to actually be scheduled or for a task to fail to be executed) as other topics in this forum and across the interweb will testify. So this may depend on some specific problem on your installation – things like prematurely terminated database connections, plugin conflicts, etc. Maybe the backupbuddy scheduling of backups works but the actual execution of the backups fails – different thing?

As regards “blame”, hmm, that’s a tricky one – in the case where loopbacks really are disabled this isn’t the “fault” of iThemes is it? Did the host who claims to provide WordPress hosting say that actually loopbacks are disabled and so they are hobbling your shiny new WordPress installation from the get go? Especially as WordPress itself recognizes this negative behaviour by hosts and _specifically_ provides a workaround for it as standard WordPress functionality so that _standard_ WordPress functionality _and_ plugins that require this capability can actually function. Shouldn’t a “reputable” host be “well aware” of the consequences of their behaviour and at least mention it to potential buyers of their hosting service (and please note that unavailability of loopback capability doesn’t necessarily affect just WordPress but can affect application behaviour in general).

I’m not sure what backupbuddy would say and whether it would mean anything to 95% of the people who might (just might) read it – maybe your host may disabled loopbacks which means they are crippling your WordPress installation in which case WordPress provides a workaround for you… Would that make any difference, don’t know? How many people would actually read that, how many would understand it, how many would it actually apply to, would they ask their host? It would probably just make life more confusing.

I’m happy that you are happy with Bluehost and, as you mention, your backupbuddy plugin is working (which probably means the main issue isn’t disabled loopbacks?) but I am constantly amazed when I read posts from people who seem prepared to forgive their host anything and lay the “blame” for any problems at the door of another. Low cost hosts are low cost for a reason – they just rely on volume, packe ’em in, pile ’em high and if a customer isn’t happy then it doesn’t really matter as there will be another along in a minute. It’s a perfectly valid business model for sure, but if you buy into it you also have to accept the consequences and limitations and not simply try and shift the responsibility for overcoming those elsewhere. Not a personal comment on you, just a general observation ??

Anyway this has probably gone way off-topic so probably best to draw a line ??

That makes more sense – basically the advice given is the standard advice for someone trying to operate a WordPress site and needing WordPress scheduling capability where the host has disabled loopbacks (or they aren’t working for some reason).

The response you may have gotten from your host sounds like a fairly standard first-line, knee-jerk response from a lot of hosts – basically they try and deny all knowledge of something and hope it goes away. I’ve had some shocking responses from hosts when they think you don’t know what you are talking about – when it becomes clear that you do it’s quite amusing when they try and backtrack and pretend it was “just a miscommunication” blah blah. “Loopback” is actually a commonly used term and is certainly used by the WordPress community – actually see here for the full run down on the requirement for the alternate cron fix: https://www.ads-software.com/support/topic/scheduled-posts-still-not-working-in-282?replies=13 (see Otto’s post a short way down). If your host support realy doesn’t understand it then shame on them; if they do understand it but are just hoping you’d drop it then shame on them again – either way they deal in servers, it’s their job to know and that’s what you pay them for ??

As regards another plugin like the one you mention – I think that has a totally different backup paradigm and in any case only does a fraction of what BackupBuddy does – I think it even mentions only backing up the core WordPress database tables so hard luck if you have any other important tables. Also you have to restore using phpMyAdmin, it doesn’t do migration etc. I don’t think it uses task scheduling as part of it’s actual backup process and you’d probably find the backup scheduling doesn’t work if loopbacks are disabled and alternate wp cron fix isn’t in place. Don’t get me wrong, I’m sure it’s a great plugin for what it does and if that’s all you need then great, go for it, but if you need more you can’t really compare the two ??

Could you please explain that statement?

The appearance of the doing_wp_cron tag on a url is related to the use of the alternate wp cron “fix” which some people have to enable because their host has disabled loopbacks and hosed their WordPress scheduling. Without that fix no scheduled tasks will be executed on the site. Their are loads of plugins that create scheduled tasks and if they cannot be run then the behaviour of that plugin is compromised.

The “cause’ of the problem is the host disabling loopbacks.

If the alternate wp cron fix doesn’t work for you then either you have to accept that you can’t use _any_ WordPress functionality that requires task scheduling; move to a more enlightened host or investigate external means of triggering the scheduling.