azrobbo
Forum Replies Created
-
I need to correct your comparison of my request to “security by obscurity”, and suggesting I read up on it. I’d be insulted if it wasn’t such a laughable comparison.
You stated – Trying to hide is not a reliable security principle. For more on that see the concept of “security through obscurity“.
Let’s define exactly what security through obscurity is:
- Security through obscurity is a reliance on secrecy of the design or implementation as the main method of providing security for a system.
- The basic fact that I use the paid version of your product clearly demonstrates that there is no reliance on secrecy.
There’s a big difference between the “desire for as much secrecy as possible”, and “using secrecy as the primary method of providing security”.
Since you suggested some research for me, let me return the favor: NIST 800-123: Guide to General Server Security
Section 5-1:
- “Remove all manufacturers’ documentation from the server.”
- “For external-facing servers, reconfigure service banners not to report the server and OS type and version, if possible.”
- “While this will not stop determined attackers, it will force them to work harder to compromise the server, and it also increases the likelihood of attack detection because of the failed attempts”
The last point – is exactly why I’m trying to accomplish; make the attackers work harder.
- Why give them everything up front because “the might obtain it anyway?”
- No it will not stop them all, but it might deter some.
- Yes, there are many bots. but, they’re not all bots. And even bots collect and store returned results.
Thank you for response.
Given that your response essentially just validates your current implementation, it seems rather clear that you will not be implementing this request.
So, I have a new simple proposal:
Can we have a special message for “manually” and “firewall” blocked IPs?
Right now these “known bad IPs” see the same “overly friendly, thank you please hack again” message that are intended for users.
Please let me know you thoughts on that.
FYI – I’ll also admit that mentioning “Wordfense” in the block pages isn’t that big of a deal, and it is somewhat of an industry-wide practice.
@wfphil – Thanks for taking this feedback and noting it as a feature request.
First – I love your product, feel like you give out a tremendous value in the free version, and the paid version is every better.
My ask is simple – Can you please allow us to specify custom PHP files for “block” and “lock” – alternatively, allow us to run a script (to re-copy customizations) after the plugin is updated?
I realize (from the thread linked above) that you were focused on users who were getting incorrectly locked out. I understand the desire to please needy customers, and it is noble.
Unfortunately, it is misplaced. As a security product, you should be focused on security first and user-friendliness second. The defaults should be locked down, with an option to make it user friendly – not vice versa (as it is now with no option to lock-down).
I strongly suspect that the only reason more people haven’t raised issues about the default messages is that they haven’t seen them.
A couple of questions that make my skin crawl when I see the default messages:
- They are so user friendly, it’s as if you don’t expect any bad actors (like hackers) to see them. Did you even consider this possibility?
- Why do you brand them “generated by Wordfence”? Do you envision that either the hackers or locked-out users are potential customers? (One is trying to defeat you, the other is likely upset with you.)
- Do you realize how many WordPress sites are out there with exactly ONE user that logs in and that’s it? They have zero interest in being friendly to anyone entering incorrect passwords and/or getting locked out.
I have a full list of “security issues” with the default messages listed in the README in my GitHub repo, and I sincerely hope you’ll take the time to review them.
Again, I actually do love your product – I just really hate this one “default” that breaks so many security best-practices.
Thanks,
Robert.- This reply was modified 9 years, 1 month ago by azrobbo. Reason: changed from md to html
Hi MTN,
I agree that copying over the files has a degree of danger, and that your method is theoretically safer. But, unless Wordfence significantly changes the way they use those files, overwriting them can’t really cause any problems. (note: I only over-right these two files & I’ve been over-writing them for a while now without issue.)
This is because (in recent / current versions of Wordfence):
- even though they are php files, they don’t do anything other than determining how much info to display & display it. (i.e. They either display an excessive amount of info, or an obscene amount of info – from a security perspective)
- essentially, they are functioning like HTML files containing text that gets displayed when called (which happens on lockout or blocking)
- they return no information back to the calling functions
- So, unless wordpress completely changes why or how these files are used replacing them should have no effect.
I’m looking to implement some sort of automated solution. Although I’m still conceptualizing the logic for my automation but it will probably function along these lines:
- It will make a backup of the “default” files after a plugin upgrade
- Compare the new “default” files against the previous “default” files (the backups from the previous version)
- If they’re the same (i.e. Wordfence hasn’t changed those files), then it will automatically overwrite them with my custom files.
- If the new “default” files are different, it will send me an alert (so I can inspect them manually) and leave them intact.
- I haven’t determine how to automate them but the WordPress action hook upgrader_process_complete looks promising
I’ve moved my custom files to a GitHub repo, the repo contains:
- my custom files
- screenshots of my custom files
- screenshots of the default files
- description of how I find the defaults lacking (from a security perspective)
- I will add an installation and/or automation script when developed (unless WordPress fixes this before them).
I welcome any feedback, comments and criticism. Feel free to post in the repo if you’d like.
Robert.
Thanks for the feedback, MTN, and thanks for your original post last year.
I tested them about a month ago for the various locked-out & blocked scenarios. Although, it would probably be prudent to test them periodically to make sure they still function as expected.
I have a shell script which copies these files after an update. Now, I just need to implement a trigger so that it automatically occurs when the plugin has updated.
I suspect the attacker is hitting xmlrpc.php, and that is what is trying multiple authentication attempts. Basically it’s the file/API that apps and jetpack use to access your site.
Do a search on “WordPress xmlrpc.php” and you’ll find out all sorts of information on that file, what it does, and the implications of restricting it.
I hope this helps,
RobertI just discovered this thread, and I’m glad to know I”m not alone in needing something more than the built in lockout messages.
For those of us who need more secure lockout/blocked messages, I’ve placed the files I use on a Public GitHub Gist
Since Wordfence is first and foremost a security product, I’m in disappointed that there still isn’t an option to provide “lockout messages” that adhere to standard security guidelines.
The built-in messages break many security principals; In short, they give the attacker way too much information:
– They tell the attacker why they can’t access the site
– Both the login-lockout and blocked messages state they are “temporary” and state to either “try again in a few minutes” or “try back in a short while” (despite the fact that the IP might be perma-banned)
– They tell the hacker exactly what utility/firewall blocked them, and even include a helpful link to the docs and homepage for said productI hope this helps some others & please add an option like this into the product (I have a paid licensed version.)