• Resolved rjspiteri

    (@rjspiteri)


    Hi there,

    I’ve just updated the iThemes security plugin to the latest version on an internal wordpress instance. Doing so a couple of pages on the site have stopped working – those pages just load a text file from disk and display the contents on screen.

    Disabling the plugin allows the file(s) to be displayed just fine. And before the update the files displayed fine too. Can someone tell me if they’ve come across something similar? Any suggestions perhaps in resolving it?

    I can’t pass on a link (the site’s internal) – but I think the only relevant bit is the file import and prep for display:

    $dom = new DOMDocument();
    @$dom->loadHTMLFile(get_bloginfo('url').'/data/whatever.txt');
    $xpath = new DOMXPath($dom);

    The code hasn’t changed (and as far as I’m told the system hasn’t either), the line that would load the HTML is generating the correct URL Path, and when I browse to that path I can view the file to be processed.
    The file that it’s trying to import is owned by apache and has a+r privileges. SELinux is not blocking access.

    https://wordpress.org/plugins/better-wp-security/

Viewing 8 replies - 1 through 8 (of 8 total)
  • Thread Starter rjspiteri

    (@rjspiteri)

    One other thing I’ve noticed is that the modsec_audit.log populates with request information regarding that file when the plugin is activated – and I’m seeing something like this:

    --ff21ba30-F--
    HTTP/1.1 403 Forbidden
    X-Frame-Options: SAMEORIGIN
    Content-Length: 236
    Connection: close
    Content-Type: text/html; charset=iso-8859-1

    So I’m guessing something needs to be whitelisted on the iThemes Security management page? (assuming that’s even relevant) The iThemes Security logs themselves do not display anything useful about this error.

    If you have the HackRepair.com blacklist setting enabled in the Banned Users section of the iTSec plugin Settings page try and disable it.
    Then see whether that makes any difference.

    dwinden

    Thread Starter rjspiteri

    (@rjspiteri)

    Hi Dwinden!
    thanks very much for taking the time to reply.

    I’ve unchecked that item – and sure enough contents are displayed perfectly now 😀
    Do you think the update set that option as a default – or should I enable it again, and in some place/config try to add our server IP as some sort of exception?

    Any advice would be very much appreciated – I’m hoping to keep things at least as secure as it once was.
    Robin.

    No, I don’t believe the HackRepair.com blacklist setting is enabled by default.
    So updating the plugin did not enable the blacklist setting.
    However the blacklist included with the latest plugin updates did change…

    It’s probably this (new) line in the blacklist that is causing trouble:

    RewriteCond %{HTTP_USER_AGENT} “^$” [NC,OR]

    It makes sure any requests with no User Agent are forbidden (403).

    Temporarily enable the HackRepair.com blacklist setting and then manually remove the mentioned no User Agent line from your .htaccess file and do a quick test.

    If the test result shows it now works you can make the change more permanent.

    Assuming your Web Server is Apache create a backup copy of the wp-content/plugins/better-wp-security/core/modules/ban-users/lists/hackrepair-apache.inc file.
    Then edit the file and remove the aforementioned line.
    Then disable (save) and reenable (save) the HackRepair.com blacklist setting. This will ensure your mod to the HackRepair.com .inc template file will get propagated to your .htaccess file EVERY time you save settings. Verify the mod is indeed now included in the .htaccess file.

    Keep in mind this change will be undone when updating the plugin in the future. Then again iThemes may decide to alter the HackRepair.com .inc template files any moment … perhaps with the next update.

    If the above info answered your question please mark it as ‘resolved’.

    dwinden

    Thread Starter rjspiteri

    (@rjspiteri)

    Hi Dwinden,
    thanks very much again – that solves my problem, I’ll mark this as resolved. Have a great weekend over there 🙂
    Robin.

    @robin
    Ah nice to hear it is now resolved.
    Don’t forget to mark this topic as ‘resolved’…

    dwinden

    Thread Starter rjspiteri

    (@rjspiteri)

    Thanks again Dwinden, doing so now!

    Hi,

    I have a similar problem and when I disable blackhatrepair.com the error is gone. Thank you for instructions.

    Error when blackhatrepair activated is like this:

    Warning: getimagesize(https://www.xxxxxxx.com/wp-content/uploads/2015/08/pretty-flow-logo1.png): failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /home/prettyflo/public_html/wp-content/themes/goodstore/templates/header/header-small-444.php on line 39

    Is this problem will be solved in the next updated?

    Thank You.

Viewing 8 replies - 1 through 8 (of 8 total)

The topic ‘Recent plugin update blocks file include?’ is closed to new replies.