Hardening ClassicPress?

General Discussion Security News
1

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)
  • Install “Really Simple Security” (formerly Really Simple SSL)
  • Install “Stop Spammers” plugin
  • Install “Stop User Enumeration” plugin
  • Install “Simple History” plugin
  • Install “WPS Hide Login” plugin
  • Install “Updraft Plus” backups plugin
  • Install “Two-Factor” plugin (by “WordPress.org Contributors”)

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.

1 Like
2

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.)

2 Likes
3

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.

4

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.

1 Like
5

I never understood Pepper either. At first I didn’t activate it, but decided to try it one day. First on one site, then all of them.

I never changed my password, was never asked to, and can log in and out with my original password.

Guess I still don’t understand it.

6

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.

Someone please correct me if I’m wrong here.

1 Like
7

Yes, that is what it says. So, it doesn’t seem to have had any effect on my password.

8

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.

1 Like
9

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.

1 Like
10

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.

11

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.

1 Like
12

This is exactly correct Tim.

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!

1 Like
13

Interesting. I will take Pepper for a test drive.

14

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.

1 Like
15

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.)

1 Like
16

@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.

2 Likes
17

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.

3 Likes
18

I stumbled upon this thread when searching for answers on basically the same question: “How do I prevent people from getting access to stuff they are not allowed to access”. I am an experienced software developer and am running some pretty high traffic business critical production systems in western Europe. Some of the answers in this thread are very worrying to me and can be easily wrongly interpreted. Also, the “security first” statement of Classicpress generates some serious questions when reading these posts.

“Security” is a pretty wide term. I think we are talking about two things in this thread:

- Network/machine security: Preventing people from getting access to the server by closing ports to services that should not be exposed to the internet. The old telnet is a good example, and ssh can be too. There are mechanisms and protections to control access to the OS and services which are not part of other installed software on the machine. This is usually known as “hardening”: Limiting OS access.

- Software security: Preventing people to bypass login screens or access resources served by an application running on a server. Let me stress that this is NOT part of “hardening” a server. There are products which are known as “Web Application Firewalls” which basically protect direct access to URIs which would otherwise be exposed to the world. Although a WAF is a nice tool, I am pretty adament that it should be seen as an “extra” layer that should not have much effect if left out.

When Classicpress states that it has a “Security first” approach, it does not rhyme with the availability of plugins like “Pepper”. If password hashing is done properly, Pepper should not have to be installed. Same goes with access to certain resources like wp_admin.php and wp_config.php. Lots of bots are scanning these URLs and the reasons for scanning these are pretty well-known and I expect Classicpress to have mitigated those problems. Of course I protect access to wp_admin and the likes in my WAF, but theoretcally I should not have to.

So:

- Yes, you should harden your OS and network to protect your machines from people trying to gain access on OS level. Close ports, use strong passwords, preferably keys to access ssh if needed.

- Yes, you should carefully consider what software you run and what URLs you open to the world. Less software means a smaller attack surface: Try to make a single-purpose machine. A Web Application Firewall (Amazon WAF, or VPS services like Pangolin) also helps.

- If software advertises itself as “Security first”, I expect that I can thoretically open it up to the world, and it should have at least reasonable protection mechanisms built-in. Examples are forcing strong passwords, don’t rely on defaults (like admin/admin), has account locking/timeouts, have strong hashing (so leaking a database does not leak passwords), minimal knowledge (don’t store user info you don’t need), don’t use user input for build queries (SQL injection), proper escaping/input filtering (UTF attacks) etc. Captchas were popular but nowadays software can “solve” a captcha faster than a human can, so I would not rely on those too much. It’s a race :slight_smile:

I trust that the Classicpress team puts great effort into creating stable, reliable, secure software (that’s why I use it, and it is performing beautifully up to now). Maybe it is a good idea to have an article somewhere which addresses these worries, and explains how Classicpress mitigates risks, and what people can do to add extra protection (and backups) should they want to. Maybe there is already a good post that I don’t know of, and we should link to it here.

2 Likes
19

And add this to the CP Docs as well. Already did this recently with some tutorial posts from the News page of the main CP site.

1 Like
20

I use the PerishablePress .htaccess firewall (among other things) and it seems to work pretty well.