12 Comments


  1. Hi Jeff
    I don’t use this plugin but I did take a look at it on wordpress.org and noticed…

    “The following video is an introduction to Falcon Engine, the new caching engine included in Wordfence 5 which will make your site up to 50 times faster than a standard WordPress installation.”

    I wondered if anyone had activated the Falcon Engine on their site and tested the speed increase.

    Reply

    1. I use Wordfence but decided against activating the Falcon Engine. We also use WP Super Cache and as far as I can tell, the “50 times faster” in FE is as a result of htaccess caching as opposed to PHP caching. Super Cache works well enough for us in that regard.

      Reply
    2. Rob

      The “falcon engine” is a solution to a problem that shouldn’t exist if security was done correctly. That is, if security was placed here as it should be for optimal performance and effectiveness:

      Attacker => HTTP server => PHP => **Security** => WordPress => Plugins

      There would be no need to cobble together a separate caching solution and introduce yet another break point as wordfence has done.

      But since security is placed after wordpress and after plugins, coming late to the party as it were, then they are left scrambling to fix a problem that they themselves created.

      The only security/firewall that I’m aware of that does it correctly and blows all the current security plugins out of the water is ninja firewall. Here are benchmark comparisons with the 5 most popular security plugins showing the difference:
      http://nintechnet.com/wordpress-brute-force-detection-plugins-benchmarks.html

      ps I am in no way related to ninja, its creators, etc. just a wordpress user who is more and more surprised every day that no one makes mention of this critical difference in how security is done and how it should be done.

      Reply
      1. LeBearUK

        Thanks for making me aware of Ninja, after further research I’ve decided to trial this as another security layer basedon the reviews and the logic.

        Reply
      2. Ed

        Classic case of believing something someone told you (or a pretty graphic) and not really verifying the information as fact. .htaccess files are processed first before PHP code since htaccess files are distributed server configuration files. Then the Ninja plugins claims are false. I don’t think this is intentional. I think they honestly believe their WAF is processed first which is incorrect/not valid.

        Reply

        1. Comment edited for you. Darn, really gotta get the site fixed so the comment editing plugin works.

          Reply

  2. I use the plugin on every site I build out. Currently there is only one site that I cannot login to via the mobile app – my business site (I love a diet rich in irony :) ) – but it doesn’t appear to be XMLRPC related. I don’t use any caching plug-ins – never saw a reason to do so.

    Reply
  3. mmaunder

    Hi Jeff,

    After receiving this feedback from our users and the WP community including Andrew Nacin we’ve put out a release 5.0.3 which fixes this issue. We’ve completely yanked the feature. I’ve also published a blog entry here explaining what we’re going to do to prevent this from happening in future:

    http://www.wordfence.com/blog/2014/04/removing-the-ability-to-disable-xml-rpc-in-emergency-release-5-0-3/

    Regards,

    Mark Maunder – Wordfence founder.

    Reply

    1. These things happen and it’s a delight to see your quick and gracious response Mark.

      Reply
      1. mmaunder

        Thanks Keith. It sure has been a crazy week. A major Wordfence release with the associated hiccups, then heartbleed on Monday which is probably the worst vulnerability we’ve all seen for years, then JetPack yesterday.

        Dare I say TGIF? Probably best not to tempt fate.

        Reply

  4. Regarding the Disable XML_RPC plugin, as the plugin author, I did not realize that it was being recommended for this use by Network Solutions. I have also found a couple of other articles relating to the DDoS attack that mention it as a way to thwart the attack.

    The plugin was not designed for the purpose of disabling pingbacks. It does one very simple thing – set the “xmlrpc_enabled” filter to false. This filter was introduced in WordPress 3.5, when the UI option to disable XML-RPC was removed and it was enabled by default. I had some edge cases where a site owner did not need or want remote publishing and wanted XML-RPC disabled to lessen his security footprint. I decided to release the plugin to the repository, in case anyone else found it useful.

    I regret that Network Solutions and others publicized it to do something that it doesn’t. I can only assume that it was not fully tested for this use case before that e-mail was sent.

    Reply

Leave a Reply