mountainguy2

Just contributing ideas, as I suspect there are other folks getting massive xmlrpc bot attacks. MTN

Bruno, there are VPN services that provide a static IP. Perhaps she could subscribe to one of those, obtain a static IP, problem solved. MTN

I’ve used both for years, no problem. MTN

In “free” version, you should get obvious options that open up when you click on “Custom Pattern.” If not, there is something wrong with your Wordfence installation or:

You might need to check the “All Options” page, under “View Customization.” Perhaps you’ve got something not checkmarked.

MTN

Yes. But test first, most modern hosting has directory browsing (by public) blocked by default. Blocking directory browsing is a basic security setting, no big deal, easy to test and experiment with. MTN

It’s against the Wordfence religion to hide login URL. Though it’s ok with them to hide your WordPress version (see top of WF “All Options” page). But in my experience, it’s quite useful to hide the login, and we do it on all our sites using WPS Hide Login plugin. Try it. MTN

Wordfence support told me some time ago that letting Wordfence do most of your blocking, instead of .htaccess rules, places less load on the server. The “G” blacklists are very robust, and trigger for all sorts of regular expression matches. In my opinion you wouldn’t want to use any of them along with Wordfence. Though you’d still want to have many of the “standard” security rules in .htaccess that are found in how-to-harden-wordpress articles.

I’ve experimented quite a bit with the “G” blacklists and found them to be too aggressive (false positives) and difficult to tune as you need to be pretty good with regex to do so.

Main thing to remember about .htaccess is it loads during _every_ page load and looks at _every_ rule. Wordfence web application firewall is more efficient. This is critical for a site with moderate to heavy traffic if you’re trying to avoid paying for more bandwidth, or preventing slowdowns. If your site is lower traffic, doesn’t matter and you can load up the .htaccess as much as desired.

MTN

Test it. If you don’t see anything odd for a site visitor, then all good.

Likewise, to learn about Wordfence front facing behavior, tunnel through a VPN and test it.

That said, if a website gets on certain lists, a user might get a message from their AV software or browser about an “unsafe site” but again you have nothing to do with that.

This is out of the scope of Wordfence subjects, but it should be said that if your site has outgoing links to blacklisted websites, you eventually want to resolve that as it’ll possibly affect your search rankings.

MTN

I’d take no action. Healthgrades looks fine. If they got on a blacklist then that’s their problem.

https://sitecheck.sucuri.net/results/www.healthgrades.com

Hi Simple, “tried” is the operative word. As your website continues to exist you’ll get thousands of such “tries.” The internet these days is basically a free zone for criminals who attack everything in sight — Wordfence allows us to see just how bad the situation is. Proceed with normal website life, run Wordfence scan for peace of mind. MTN

WFASA

I appreciate your theory that “Some people may be using the case sensitivity in banned URLs to block certain things and not others.” But since the Wordfence “Block URL” feature only blocks URLs that do _NOT_ exist, I doubt what you suggest is very common. Just thought I’d get that out there, as it’s easy to forget that the “Block URL” feature has no effect on existing files.

P.S., to solve this problem with Wordfence I was all excited to change my Apache server so it converted all incoming URI requests to lower case. Turns out that’s not at all acceptable, as Apache Linux is case-sensitive when it comes to URI requests, and thus I’d end up breaking access to any existing mixed case URIs, for example photos such as /IMG_5678.jpg/ would result in a 404 error if requested as /img_5678/ Frustrating.

Conclusion: as suggested by WF Support in message above, there needs to be an option within Wordfence to make the “Block URL” feature case insensitive.

Constant problem with communication here, come on WF support folks, clearly the word “access” is being used in place of the more technical term “request.” Have mercy on us.

A toggle for case sensitivity would seem to be a basic option for Wordfence, thanks for considering it.

MTN

Why is this marked as “Resolved?” It’s clearly an ongoing flaw. MTN

Sigh, yet another reason I canceled my Premium Wordfence. I suspected attackers would eventually figure this out, and start adding random caps to their attack URLs. This would be so easy for Wordfence to fix…

But since Wordfence has better things to do than repair their software flaws, we as website managers must look at our options. It’s possible through the Apache server configuration settings to convert all URLs to lower case. It can be done in .htaccess, as well as in httpd.conf. Good tutorial here:

https://www.askapache.com/htaccess/rewrite-uppercase-lowercase/

I’d prefer to do this at server level with httpd.conf, that way it would cover all the sites on my server, but I wonder if doing it that way has a downside?

NOTE: To be sure this was still an issue I tested just before writing this post. Adding an upper case character to a blocked URL resulted in a bypass of the Wordfence
“Immediately block IPs that access these URLs” feature. Terrible. Unconscionable. Please Wordfence, could you fix this !?