Problem firewall with Justified Image Grid plugin

Hi @wp-opti, thanks for reaching out to us on this.

As disabling extended protection solved the issue rather than disabling Wordfence altogether, I would suggest Learning Mode so that the firewall doesn’t feel it needs to check the actions the JIG plugin is performing when page load occurs.

Firstly, reenable extended protection.

Secondly, from the Wordfence Dashboard click on Manage WAF. Then you will see Basic Firewall Options > Web Application Firewall Status. Change the option to Learning Mode. Now perform the page loads that were previously causing issues. This will help Wordfence learn that these actions are normal and it will allow them in the future. After you have finished loading up pages containing the JIG plugin, switch the WAF from Learning Mode back to Enabled and Protecting. Now test to see if these pages work at the normal/expected speed.

https://www.wordfence.com/help/firewall/learning-mode/is an amazing resource for learning more about the WAF and learning mode.

Let me know how you get on!

Peter.

Hello Peter,

Thanks for your help!

I did what you described but unfortunately it did not help…

The page loads are allowed by Wordfence, that is not the problem. Problem seems to be that WF is scanning these Timthumb request or something like that.

Alwin

• This reply was modified 4 years, 1 month ago by Alwin.

Update: I have tried a lot of settings but nothing helps. The only thing that does help is disabling the extended firewall protection.

I looked at other free security plugins like the free Sucuri plugin. This plugin however does not provide a firewall at all (free version) so now I am thinkig to just keep the Wordfence firewall at the basic protection level.

Question: is keeping the firewall on Basic protection level a big security risc?

Seems to me that it’s always better then a security plugin without a firewall at all?

Hi @wp-opti, thanks for trying that for me.

Can you send a diagnostic report to wftest @ wordfence . com? You can find the link to do so at the top of the Wordfence Tools > Diagnostics page. Then click on “Send Report by Email”. Please add your forum username where indicated and respond here after you have sent it.

Note: For the fastest response time, please make sure and add any information or questions directly to this topic and not the email address above unless asked.

Thanks,

Peter.

Hello, I have sent the report (forum username=wp-opti)

Hi @wp-opti, thank-you for sending that over for us.

We’ve taken a look at your site to test loading the image grids. We do see requests to timthumb.php for each image, but nothing in these requests should make it slow on any particular Wordfence firewall rule. When the firewall is optimized, a decent server and recent PHP version should certainly execute without the delay you describe.

When taking a look at the diagnostics, there may be a subtle but key configuration difference on PHP 7.4 that we have seen cause slowdown in rare cases elsewhere. On your hosting plan for this site, are you able to temporarily switch it to PHP 7.3 to see if the slowdown issue still happens?

If that change makes it faster again, I will need to relay some further information about PHP 7.4 configuration for passing on to your hosting provider.

To answer your earlier question, whilst we do not recommend only running with the basic protection unless you have very limited resources, we agree that having some is beneficial although hope to get you back up and running with extended protection soon.

Thanks,

Peter.

Thanks for your help!

– I switch back from Basic protection to extended protection
– The load time changend (again) from around 1,5 seconds to 6 seconds
– Then I changend the php version from 7.4 back to 7.3

Changing the php version did not make any difference.

The only thing that solves the problem is disabling the Extended protection….

Hi @wp-opti, thanks for trying those and I’m sorry you’re still experiencing problems.

As the images are loaded one after another, we feel that fractions of a second that would normally be insignificant are adding up to a larger wait. This delay still seems higher than it should be, so that could be worth discussing with your host in case there’s anything they can do for you.

You may need to leave extended protection off. Not using extended protection does increase risk as certain firewall rules can block malicious intent before page load. As timthumb.php is accessed directly without loading WordPress, that file will be unprotected. Make sure that the plugin always has the latest version of that file, and keep a close eye out for for latest updates.

If you are able and willing to troubleshoot further with us, sending a copy of the Wordfence diagnostics as before, but while the site is running on PHP 7.3 (and even one running 7.2) would be very helpful to see if there are consistencies between that and the potential speed issue we identified for PHP 7.4 on your host.

Thanks again,

Peter.

When I try running on PHP 7.3 an PHP 7.2 to send you the Wordfence diagnostics, should I do that with or without the Extended Firewall protection enabled?

Hi @wp-opti,

Please send those with the Extended Firewall Protection enabled.

Thanks again,

Peter.

Hello Peter, I have sent both the php 7.2 and php 7.3 reports.
Thanks again for the help ??

Hello Peter, did you manage to find anything in the diagnostic reports?

In the meantime I have done a lot of tests:
– with the wp-rocket settings
– with different php versions
– with disbaling other plugins

But the only thing that is solving the slow loading is still disbaling the extended firewall protection!

So now I have decided to leave the firewall at the Basic protection level for now. But I do have some questions about that.

Since the firewall is now loading at the same time as WordPress and not before (like in the extended modus) maybe it is a good idea to add some additional security related code to my .htaccess file?

That way I stillcan get some extra protection before WordPress is loaded!

At this moment I already have this code in my .htacces file:

# protect wpconfig.php
<files wp-config.php>
order allow,deny
deny from all
</files>

# Disable Directory Browsing
Options All -Indexes

# protect .htaccess
<Files ~ “^.*\.([Hh][Tt][Aa])”>
Order allow,deny
Deny from all
Satisfy all
</Files>

# Disable xmlrpc.php
<Files xmlrpc.php>
Order Allow,Deny
Deny from all
</Files>

And I could add some more like:

– Block readmefiles
– Block Bad Bots
– Block Access To wp-includes Folder And Files
– Block cross-site scripting (XSS)

Would that be a good idea, to use the .htaccess file to compensate for the disabling of the extended firewal modus?

Thanks very much for all your help ??

Alwin

Hi @wp-opti, I apologise for the delay. We received your diagnostics just fine but needed the developers to take a look over the setup in case there was anything we had encountered before that might be causing the go-slow on your site.

We still think that the number of image loads on a page, plus scaling on-demand when the page is visited, plus the firewall acting on each image request is quite demanding for the server your site is hosted on.

A page cache may help if you wish to keep extended protection turned on, although occasionally when the cache expires, the first visitor will experience the slower page you are seeing at the moment.

We don’t recommend blocking many things with .htaccess as it makes false positives harder to detect, but xmlrpc.php as you mention is fine.

Thanks,

Peter.

Thanks again!

As far as I can see Wordfence does not have settings for these security:

– protect wp-config file
– block directory browsing
– protect .htaccess file

So why not just add rules to my .htaccess file to have these extra security?

Hi @wp-opti,

The few changes you mention above are fine to add if you wish to and it gives you peace of mind that those files cannot be accessed.

The other .htaccess changes you’d mentioned earlier like blocking XSS or files in wp-includes are ones where we would be concerned about false positives. If you block “bad bots”, try to avoid plugins that write to .htaccess when it thinks there are attacks, we’ve seen issues with multiple writes to .htaccess overlapping and breaking a site.

Thanks again,

Peter.