There are plenty of articles on the web about how to harden/secure WordPress, which seems to ship with a lot of exposed vulnerabilities. I’m curious how much of that also applies to ClassicPress and what the “best practices” would be?
Okay, so first of all, most of the websites I run are personal ones for myself or friends/family, but I do have some I manage for small businesses and organizations. For the most part the people I run these for aren’t very tech savvy and don’t want to (or can’t) afford to spend a lot on their websites (if they could they wouldn’t be coming to me to do it for them and none of them consider their websites “mission critical”).
Most of these sites have only a couple users (including me) and are not open to registrations, which locks out a LOT of the potential security and spam problems. But a couple of them DO have open registrations.
Anyway, typically when I set up a new WordPress installation I will:
Add code to the theme functions or install a plugin to enforce strong passwords
Add code to hide WordPress version
Change the default Admin username
Disable File Editing
Disable PHP execution in the “Uploads” folder
Limit login attempts
Change WP database prefix
Disable XML-RPC
Turn off Link Notifications (pingbacks/tracebacks)
Those would all be the free versions of those plugins, and that combo seems to do a pretty decent job, along with some additional tweaks to .htaccess files.
At least one of my people has a host that does daily backups of their site. For the others, which have very limited activity, I do a monthly manual backup on the site with Updraft Plus and then download and archive those files to an external drive as well.
It looks like “Stop User Enumeration,” “Simple History,” and “Two-Factor” plugins are “incompatible” and cannot be installed. There are, of course, other plugins that do the same thing that aren’t listed as incompatible, but I’ve never used those before. I know some of this could be hard-coded into the theme or a custom plugin, but I’d rather use a popular plugin I know is being updated.
I can’t seem to find a nice security guide like the ones for WordPress. Just how much “hardening” does ClassicPress need? This is one of the things that’s making me apprehensive to switch some of the sites I run over to ClassicPress.
First, ClassicPress uses a much stronger form of hashing than we inherited from WordPress. We use bcrypt instead of md5.
Secondly, ClassicPress ships with a Pepper plugin. You can also download it from ClassicPress Pepper for Passwords | ClassicPress Plugin This is in addition to the built-in “salt” that has traditionally been added to the hashing mechanism.
Third, the ability to disable both Emoji and XML-RPC is built into ClassicPress. Just go to Settings -> General and scroll down to check the boxes to turn them off.
For logging of regular tasks, I use Stream. I also use Updraft Plus. Hiding the version of WP/CP doesn’t add to security because would-be hackers don’t check for that first; they just hack. (You might like to do it for cosmetic reasons, but it’s not achieving anything in terms of security.)
I guess I still don’t understand what Pepper is or does, exactly, or why I’d want to use it over, say, a 2FA plugin? After reading posts here about people getting locked out of their sites by it it felt risky to activate it. Though I admittedly have no idea how “salt” works either. About all I know about hashing is that you get a long encoded string of gibberish, I’ve no idea what makes one mechanism better than another.
Hashing is one-way encryption, but faster computers mean a weak hash can be brute-forced. A salt is a random string added to the password before it is hashed. This means that a password stored in one database will have a different string from that stored in another database, and so hackers can’t just hack one site and get into them all.
The problem is that the salt in WP/CP is stored with the code, so hackers might be able to brute force the hash if they find it. The point of the Pepper plugin is to store another random string in a file, away from the rest of the code or the database. This means that it can be discovered and used only if a hacker has already taken over the whole site anyway.
Once you activate Pepper, everyone will need to change their password, including the person currently logged in. (That’s also true if you ever change the Pepper string.) Some people using Pepper didn’t realize that and so got logged out.
As I understand it, there are two steps: (1) activate the plugin, then in settings (2) set a pepper (the random string) .
That is, your plugin is activated but you have not yet asked it to set a pepper. Check your settings. They problably say “plugin not yet using a pepper” (or similar; I forget the exact wording). It’s after setting the pepper for the first time after activation that the passwords have to be reset.
If you look at settings after setting the pepper, you see “Renew pepper.” That is, you have the option to renew a (e.g., compromised) pepper, which will also require password reset.
Ok, so I went through the “Community Feedback” forum to see what security-related proposals were made and either implemented, are planned, or were declined. From that I gather I still need to take my own measures to:
enforce strong passwords
limit login attempts to prevent brute forcing passwords
change the table prefix
change/hide the login URL from /wp-admin or /wp-login
prevent usernames from being exposed
add math captcha or 2FA to login
block bad queries
disable theme and plugin editors
In that other thread most of the suggestions to close those exploits by default in the core were “declined” saying it should be handled by a plugin. I don’t really agree with that, I think it’s an opportunity for CP to be more secure than WP out-of-the-box without any plugins. Without admins having to change settings or install a hodgepodge of plugins, trusting they’ll be maintained, remain compatible, are coded rights, and won’t be the weak link that gets the site compromised.
These measures should be in the core IMO. Especially with the mission statement asserting “We aim to provide a CMS that is…secure…” It doesn’t seem much more secure than WP, which isn’t very secure at all or we wouldn’t need a pile of third-party plugins just to secure it.
Many of those things are handled by a good host. If we put them in core, there’d be a problem of two things trying to do the same thing, which is a recipe for disaster. That’s why they are better in plugins; if your host doesn’t provide them or you run your own server and don’t want to implement these things at server level, you can add a plugin to do so.
That’s why we provide the Pepper plugin.
I’m also intrigued that your list doesn’t mention the hashing algorithm for passwords. I’d put that way above most of the things you’ve listed.
I didn’t mention hashing because you said CP already uses a better one than WP and I frankly don’t know enough about hashing to know what makes one thing better than another. I don’t know if any of the plugins I usually install do anything in that regard.
While there are certainly good hosts and plenty of users/admins who can implement server-level fixes, it seems to me it’s bad security to assume there are good hosts and well-informed and capable users. Why not implement protective measures for everyone as default and more advanced users with good hosts can disable those built-in measures in favor of their own? Or maybe the install script could detect what measures are implemented on the server? It seems to me it would be better to ship CP locked-down and make people manually open/disable stuff if they had some reason to.
Anyway, that’s my opinion on it. I guess I’ll have to figure out an alternative slate of third-party plugins I can trust to secure CP since some of my old standby ones apparently won’t work. And since some of the sites I run for people ARE on cheap, bad hosts I didn’t choose that don’t let you configure much of anything.
We don’t assume anything. But if we start adding code that hardens security, and someone is on a host that already does that (like mine, for example) there will be a conflict. That’s the issue.
Security is actually much better handled outside of ClassicPress, so that it’s already dealt with before it ever touches CP. This is why I always recommend getting a good host.
As a company that hosts our own sites and clients, and manages clients elsewhere, the first line of security is the network and server itself. It’s why we use Liquid Web to host combined with a server level security such as BitNinja Server Security. Many hosting companies use Imunify360 etc. That probably prevents about 90%+ of the real threats.
Security plugins on CP and WP of course is helpful. It can help to catch what gets through and protect the login pages. But I see too many people loading up multiple security plugins, running into piles of conflicts, and then wondering why their locked out or their site doesn’t work.
The more security plugins you add to your site the more problems your going to have and the slower it will run - simple as that, and the more it will compound from there. You need one good security plugin (with ReCaptcha on the login/forgot password pages) and that’s it.
Honestly, security plugins don’t help much in an insecure hosting environment. I’m not saying don’t add a security plugin. What I’m saying is don’t load up on them. As Tim says, get a good host!
How do we know what makes for a good host? What specific things should we be looking for? What configurations should we be making on our server if we have to do it ourselves? What security plugins would be recommended?
Perhaps some of these security measures deemed better placed in a plugin rather than the core should be plugins maintained by the CP developers? So we can be assured they are trustworthy and will continue to be maintained and compatible with CP? Because, as noted, some of the plugins I’ve used for years with WP can’t even be installed in CP. As the development of CP moves further away from WP this is only going to become more of a problem with third-party plugins whose authors are coding for WP - and may not even know CP exists.
This is what I was talking about in my OP, there is not a simple hardening GUIDE for us to follow for ClassicPress and no way for a user (not a developer) to know what from a WordPress guide applies, and some of it can’t be applied because of incompatible plugins.
Not everyone is going to be as knowledgeable as you are or understand best practices or why they should use them. We need a guide explaining what features make a host “good” and how to secure a server and what plugins we should or shouldn’t use or consider to avoid the conflicts you’ve mentioned.
I suggest you look at what BitNinja and Immunify do to give you an idea of what you should be looking for from a host (or yourself if you choose to DIY).
As for steps you can take within your own site directly, I suggest you look at what you can do to your .htaccess file. That’s the one primarily responsible for security (as long as you’re using Apache or Litespeed for your server). You can block access to specific locations there, prevent user enumeration, and set Content Security Policies, among many other things. (If you’re using nginx, you’ll have to ask someone else as I have never used that.)
@KMH my response was not a direct attack on your post, nor intended as one. You are asking all the right questions.
Typically, hardening is done at the sever level and not the site level. For example changing the SFTP port, closing other ports if needed, some kind of anti-flood or anti-DDOS, hardware and or software firewalls. Closing XML-RPC server wide etc.
A security plugin is definitely helpful, and I recommend clients add one. but if you add too many they will conflict. That is what I was trying to say.
I’ve had clients in hosting where the chmod and Apache restrictions were so tight, nothing ran well and we ended up moving them.
What Tim was explaining, is that if you try to harden ClassicPress at core it will create all kinds of problems, as hosting and site setups are not all the same.
Honestly, get a half decent host- that has some
Kind of sever security in place, run a security plugin and call it a day. And most importantly backups to recover from.
A security guide is a good idea. Maybe I can do a blog post on what we do for our WP and CP sites as an example. I had one planned for WooCommerce security best practices as another example. But these are pretty general guides.
It’s a little tricky as people have different setups and requirements. And there are others here with far more in-depth knowledge than I.