Support » Plugin: NinjaFirewall (WP Edition) - Advanced Security Plugin and Firewall » WP subdirectory install not supported

  • Resolved GermanKiwi

    (@germankiwi)


    Hi, I am running WordPress in a subdirectory of my site, which is a supported configuration described here.

    So my site is available at http://www.example.com but the WP install itself is located at http://www.example.com/wp/

    Therefore, on the General Settings page of WordPress, my “WordPress Address” is http://www.example.com/wp and my “Site Address” is http://www.example.com.

    I’ve just installed the NinjaFirewall plugin, but it’s not working, because it does not appear to support this configuration. It tries to find (or create) the .htaccess file and php.ini file inside the subdirectory (www.example.com/wp) but this is incorrect. The .htaccess and php.ini files should go in the root directory at http://www.example.com.

    Therefore, when I click the “Apply changes” button, and then I click the “Test NinjaFirewall configuration” button, it simply takes me back to the very first page again (the page which has the button “Enough chitchat let’s go”).

    Can you kindly fix this, so that the plugin supports the situation where WP is in a subdirectory?

    Thanks!

    http://wordpress.org/plugins/ninjafirewall/

Viewing 15 replies - 16 through 30 (of 31 total)
  • Thread Starter GermanKiwi

    (@germankiwi)

    BTW: this new error message also appears in big letters on my public, front-facing webpages, for everyone on the internet to read… 🙁

    Plugin Author nintechnet

    (@nintechnet)

    Regular plugins don’t need to parse the wp-config file, everything is handled by WordPress.
    NinjaFirewall works before WordPress, hence it needs to do that itself.
    If you remove DB_NAME, DB_USER, DB_PASSWORD, DB_HOST and table_prefix, you will end up with the same red critical message on the screen.
    It must read the config file line by line, it cannot use PHP include() or require() functions (which would follow your require_once() instruction) because the wp-config file contains that line:

    require_once(ABSPATH . 'wp-settings.php');

    This would load the core part of WordPress before NinjaFirewall.

    Thread Starter GermanKiwi

    (@germankiwi)

    I see. I wonder if there could be another way to tell NinjaFirewall where to find my “config.php” file (the one which contains my database settings, which I have located outside of the document root).

    I just had the idea of some kind of configuration file for NinjaFirewall – it could be located in the root folder for example (independent of WordPress) – and NinjaFirewall could check for the existence of this file, and read it, and this file would point to the location of an alternative wp-config.php that exists in a non-standard location, as in my situation.

    This way, NinjaFirewall could still obtain the database settings from the alternative wp-config.php file, and still run itself before WordPress, and I still get to keep my wp-config.php file in an alternative location for extra security.

    Does that idea make sense? Would it be a solution that could work?

    Plugin Author nintechnet

    (@nintechnet)

    We cannot do that because that may work for you, but will not work for most shared hosting accounts using, for instance, open_basedir restriction.
    If you need to change the firewall.php config, you have one single choice: open and patch it 🙂
    Keeping the wp-config file is not a security issue. Most databases listen on localhost, and if a hacker was able to read the file and to get the DB pass, it would not be able to connect to it. It would be way much easier for him to find a vulnerable plugin to access the DB (there are plenty of those weak plugins!).

    Thread Starter GermanKiwi

    (@germankiwi)

    Unfortunately for me, my database server (from my web host provider) is not limited to listen on localhost only. It is accessible over the internet, and so the database hostname in my wp-config.php file needs to point to the full hostname of the SQL server (like “db.example.com”).

    That’s why I keep my WordPress database settings in a separate config.php file that is outside of the document root, for security. The benefit of this security technique is described here and also in the WordPress codex – it’s a recommended security feature.

    I understand your point that “what will work for me, may not work for others”. But what about the idea of having an *optional* configuration file for NinjaFirewall, which contains the path to my alternative config.php where my database settings are contained – that means, if this optional configuration file exists, then NinjaFirewall will read it and follow it. But if it doesn’t exist, then NinjaFirewall will behave like normal/default and look in the normal place for the regular wp-config.php file. That way, every situation is covered. Surely this could work?

    I really don’t want to move my database settings back into the default wp-config.php file for security reasons, because of what I described above. I want my site to be as secure as possible. 🙂

    Thread Starter GermanKiwi

    (@germankiwi)

    BTW, I’m happy that 1.1.2 works really perfectly now with my subdirectory installation of WordPress! I just tested it again today with a brand new installation of NinjaFirewall, and it was able to detect the subdirectory and create tne php.ini and .htaccess settings in the correct place, no problem! 🙂

    Plugin Author nintechnet

    (@nintechnet)

    But what about the idea of having an *optional* configuration file for NinjaFirewall

    WordPress will delete the file during each upgrade. At this stage (firewall initialization), you cannot rely on the DB or an external file to store the configuration.
    You have 2 choices:
    1) Either patch the firewall.php: easy to do. For each upgrade, you will need to download the new ZIP file from this site, patch the firewall.php and upload all files via FTP (or upload them via WP admin console plugin page).
    2) Or ensure that your user account has the correct privilege on the DB server: connection to the DB should only come from that user and IP. Nobody else should be allowed to connect to it.

    I would choose 2) because having a DB accessible to the whole world is a much greater risk IMHO.

    Thread Starter GermanKiwi

    (@germankiwi)

    But WordPress won’t delete such a configuration file if it’s in the root folder or some other location, other than the plugin folder. So that would still work then, right?

    Unfortunately these other 2 choices are not an option for me. I need to allow normal, automatic plugin updates via the WordPress Admin (without patching and FTPing), so the client can update automatically etc.

    And even if the DB server is restricted to only my web server’s IP, I still would not want to move my wp-config.php back into the WordPress directory. There is still a big security advantage in keeping this file outside of the web root. Did you read the explanation in this article? (In the first Answer of the article).

    There it explains that not only is the database information from wp-config.php very sensitive info, but also “The authentication keys and salts can be used in any number of potential hijacking attacks.”

    It goes on to say, “Conclusion: configuration files should always always always be located outside the web root. If you care about security, you will move wp-config.php outside your web root.”

    This is an officially supported and recommended practice by WordPress for security purposes, so I hope that you can understand the reason for it, as the developer of a security plugin like NinjaFirewall! 🙂

    So what about putting a configuration file in the root folder where it won’t be deleted by WordPress during each upgrade? Could you consider this as an option?

    Plugin Author nintechnet

    (@nintechnet)

    I totally disagree with that article: to me, hiding a file and pretending to be safe is nothing but a big weakness 🙂
    Most hacks we are dealing with on a daily basis, exploited vulnerable plugins to gain access to the DB. That is so easy to do.

    But regarding your question, the only reliable possibility I can see would be for the firewall to search for a wp-config.php file located in the directory above the server document root. Then, if there was one, it would use it. Otherwise it would use the one located in the current directory.
    That would require some testings though.

    Thread Starter GermanKiwi

    (@germankiwi)

    I’m not sure why you think that moving the file outside the web root is only “pretending” to keep it safe! The article explains all the reasons why this is legitimate, real-world safety, and it gives a real-world example of a bug with Plesk that resulted in the PHP interpreter being disabled and exposing the config file.

    This technique might not protect against an exploited plugin, but that doesn’t mean it’s useless. The more measures we can take to harden WordPress, the better – every technique helps – right?! 🙂 The best security is using multiple layers of protection – multiple techniques to protect multiple things. This particular technique protects against the possibility of the config file being exposed when the PHP interpreter is accidentally disabled. It really does work and it really is valid, which is why it is also recommended in the official Codex, as well as on numerous other security blogs and articles, in addition to the one I quoted. 🙂

    Anyway… your idea of putting the config file in the directory above the doc root is a good one. But what about having a special NinjaFirewall config file in that location (above the doc root) – eg. a file called “ninjafirewall.cfg” or similar – which is above the doc root, and this file contains the path to the actual wp-config.php file where the DB stuff is located. Would that work?

    This means I can still keep my wp-config.php in another folder located elsewhere on the server, and NinjaFirewall will know where to find it. (And if this “ninjafirewall.cfg” file doesn’t exist, then the NinjaFirewall plugin just behaves the normal, default way like always).

    Good idea??

    Plugin Author nintechnet

    (@nintechnet)

    Yes, it is possible too.

    Thread Starter GermanKiwi

    (@germankiwi)

    Great! Please let me know if I can help with any testing. I’m looking forward to being able to use this plugin on my site!

    Plugin Author nintechnet

    (@nintechnet)

    I added the optional configuration file feature today to the latest beta version 1.1.3, which is available here http://nintechnet.com/beta/

    How to use it: http://nintechnet.com/nfwp/1.1.3/

    Thread Starter GermanKiwi

    (@germankiwi)

    Nice!!! I’ve just installed the beta and tested it, and it works perfectly! I really like the way you’ve implemented this, using a .htninja file etc. And it even warns me about setting the permissions of the .htninja file to read-only, which is a nice bonus. Thanks for doing this!

    One question: will the beta version automatically update to the final 1.1.3 version when that is released, using the normal, built-in plugin update method? Or will I need to manually upload 1.1.3 Final once it’s released?

    Plugin Author nintechnet

    (@nintechnet)

    WordPress should automatically update it to 1.1.3 when available, because it relies on the version number that is displayed in the “Plugins” page (“Version 1.1.2”).

Viewing 15 replies - 16 through 30 (of 31 total)
  • The topic ‘WP subdirectory install not supported’ is closed to new replies.