Protect external WP-Cron

[thetwopct]

From WP Scan:

The external WP-Cron seems to be enabled: https://events.linuxfoundation.org/wp/wp-cron.php | Found By: Direct Access (Aggressive Detection) | Confidence: 60% | References: | - https://www.iplocation.net/defend-wordpress-from-ddos | - https://github.com/wpscanteam/wpscan/issues/1299

[thetwopct]

From reading the Pantheon docs it seems that using WP Cron is not recommended: https://docs.pantheon.io/guides/wordpress-developer/wordpress-cron

Pantheon's WordPress upstream disables WP-Cron by default.

If I understand it correctly, they recommend disabling WP-Cron and then relying on the Pantheon Cron to trigger WP Cron.

@cjyabraham Could you take a look and see what you think?

[cjyabraham]

Ok. I can see the benefit, in general, of using Pantheon cron instead of wp-cron. I guess one downside to consider is it ties us more closely to Pantheon which would make any future platform change more difficult.

In our case, I'm not sure we really face a problem with running wp-cron. Perhaps we should check our server logs to see if it is getting attacked directly in a ddos attack? I don't think wp-cron would be run too often from regular site traffic because 99% of our traffic will hit the cache.

These are just my initial thoughts and the issue requires more research...

[cjyabraham]

I re-read this doc. I wouldn't say that Pantheon is recommending people not use wp-cron, it's just that they provide Pantheon cron activated by default instead of wp-cron. I don't think there are any particular downsides to using wp-cron we need to worry about right now, from what it says on that page.

From reading the links provided in wpscan output, it doesn't seem they can say anything conclusive regarding wp-cron being and ddos attack service, however, it is true that we can hit the url here and it returns a 200, whether you are logged in to the wp-admin or not. This means users can bypass the cache CDN layer and hit the site directly through this url, causing system churn. Is that a problem? The rest of the site will still be served via CDN so won't register any slowdown. The difference will only come when the cache needs to rebuild from source as it does, once every 6hrs, or if an editor is editing in the wp-admin.

I think basically we're quite protected from DDOS attacks since 99% of requests get served by edge nodes of the CDN, so there's no centralized attack surface for any DDOS. For an attack to be successful, it would need to overwhelm several hundred CDN nodes at the same time.

We can keep this issue open in case other thoughts arise.