Hey @dciphered,
This particular issue (custom block pages) has come up a few times in the past, but not frequently enough to make it a priority. To answer your questions.
1. Of course, we realize that attackers will hit the block pages. However, our customers are in control of their own blocks, and therefore there will always be humans that get blocked intentionally, and sometimes unintentionally.
2. Mentioning Wordfence on the block pages makes it easier to debug false-positive blocks. We don’t see any risk in attackers knowing which software they were blocked by. A) They could figure that out anyways if they actually cared and B) Trying to hide is not a reliable security principle. For more on that, see the concept of “security through obscurity”.
3. People manage to lock themselves out sometimes. That’s a far more significant concern to us than that an attacker would see the word “Wordfence” on a block page. I’ll also add that the vast majority of attacks against WordPress sites are bots programmed to run tests on WordPress sites to see if they can get in. They don’t care why they get blocked; they just automatically move on to the next website until they find one that is vulnerable.
With this said, I’ll share your thoughts on the need for whitelisting the error/block pages.
Thanks,
Gerroald
Hi Gerroald,
Appreciate the detail within your reply however it deviates off point to my question.
I’m well aware the anatomy of cyber attacks and the kill chain process, especially in context of WordPress, and “security through obscurity” is a complimentary principle with absolute value when it comes to a good protection strategy, albeit, on it’s own is not enough.
Most seasoned security folk will manage risk through a multilayered approach (a solid defence in depth strategy) and obfuscation makes part of that. There are many ways to throw attackers off course (if you know what you’re doing) when it comes to hiding your WP deployment however when you have a WAF solution with neon lights that tells the attacker they’ve been blocked by a Worpdress plugin, then it defeats the purpose of what I’ve mentioned above.
So back to my point, having a custom error page helps alleviate this issue and it “absolutely” helps with security which is no doubt why you’ve had this topic asked before. It’s a simple question with a simple answer – can it be done without modifying Wordfence code/php files? Most network and application layer security solutions provide the ability to customise error pages, that’s what we need here.
I hope this adds further clarity to my request.
Hey @dciphered,
I appreciate your feedback and completely understand.
This isn’t currently possible without modifying Wordfence core code. However, there is a feature request filed for this. And I’ll definitely share your thoughts on the matter.
Please let us know if anything else comes up.
Thanks,
Gerroald
