Immediately block list not being honoured

  • We use the “Immediately Block” list in conjunction with our 404 handler to detect when the bad guys are attempting to access and exploit a web site function which we don’t have.

    In our Immediately Block list, we have “/e/*” but when an ip address (220.167.92.54) tried to access “/e/data/js/jscolor/hs.png” on May 31, it wasn’t intercepted by Wordfence but was sent through to our 404 handler instead. We would have expected the address to have been added to the Block List with the reason “Accessed a banned URL”.

    Why would this have failed?

    There have been other examples of this recently, too. Current version being used “Version 7.11.5”

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Support wfpeter

    (@wfpeter)

    Hi @dastafford, thanks for reaching out.

    Custom settings and blocks can be secondary to firewall rules or our global blocklist hitting first, so it’s not uncommon to see different reasons sometimes but you’re right that a 404 would most likely come after Wordfence has checked all of your settings too (provided the firewall is optimized rather than in “Basic Protection”).

    So I can try the path myself, and see why the block may not be kicking in, could you send a site diagnostic over as it’ll contain your domain for me to use?

    You can send that to us at wftest @ wordfence . com from the Wordfence > Tools > Diagnostics menu. Click on “Send Report by Email”. Please add your forum username where indicated and respond here after you have sent it.

    NOTE: It should look as follows – Screenshot of Tools > Diagnostic > Send by Email

    Thanks,
    Peter.

    Thread Starter dastafford

    (@dastafford)

    Hi Peter

    Thanks for your reply. Site diagnostic email is winging its way to you now.

    Regards

    David

    dimal

    (@dimalifragis)

    @dastafford Hi,

    Do you run ANY PAGE caching plugin?

    Thread Starter dastafford

    (@dastafford)

    Apologies for the slow response.

    No, there are no page caching plugins. But why would that affect this? Surely the firewall is the first plugin to evaluate any request. If it is not, it’s not really a firewall.

    I want to automatically add ip addresses to the block list if they try to access something with a known vulnerability regardless of whether we use it on our site or not.

    For example, today someone tried to access the url /tinyfilemanager/tinyfilemanager.php

    That doesn’t exist on the site but, even if it did, they would have no business accessing it. In our list of “Immediately block IPs that access these URLs”, we have “/tiny*” and so the IP address should have been blocked but, instead, the attempt to access it was caught by the 404 handler.

    @wfpeter I sent you the diagnostic file and alerted you to that. Did you find anything useful in the data?

    Thread Starter dastafford

    (@dastafford)

    And can someone explain to me why my posts need to be moderated? I just received the following message after my previous post:

    Your post is being held for moderation by our automated system and will be manually reviewed by a volunteer as soon as possible.

    No action is needed on your part at this time, and you do not need to resubmit your message.

    dimal

    (@dimalifragis)

    @dastafford PAGE caching plugins (not object caching) is a grey area, since some features do NOT work, as Rate Limit for example.

    The reason is simple: the cached html page is SERVED BEFORE anything else. WHY? Because in case of mod_rewrite mode, .htaccess has the HIGHEST priority, in case of PHP mode … i have no idea why. But it is what it is.

    • This reply was modified 9 months ago by dimal.
Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Immediately block list not being honoured’ is closed to new replies.