Security for your CiviCRM install is important, especially this time of the year. Because of two recent, massively exploited vulnerabilities in Wordpress, I'm posting this with some simple advice for small organizations that might not think they can do anything about security, or that it might not affect them.
There are specific, measurable costs to you as a site owner when vulnerabilities in your site/server are exploited. In addition there are future costs to both your organization and to the circles of community around you (the CiviCRM community, the open source community, and the Internet at large). These are largely immeasurable but potentially much greater. Unfortunately, that often means that security measures don't get the priority that they deserve. And yes, capitalism makes this worse.
A couple of weeks ago, I posted this angry screed about a recent vulnerability in GoDaddy's so called "managed wordpress service". So I can't help but feel even more angry today when I read the headline 1.6 Million WordPress Sites Hit With 13.7 Million Attacks In 36 Hours From 16,000 IPs.
I feel sympathy for small organizations that are financially squeezed and are looking for the right choice for CiviCRM hosting. It's easy for paid security experts to say "don't use shared hosting" and "pay for knowledgeable security consulting", but that doesn't feel like realistic advice. I could at this point plug my own services, but the one piece of advice I want you to take from this blog post is this: your CMS hosting (for Wordpress, Drupal or Joomla) doesn't have to be where your CiviCRM lives.
That's advice that flies in the face of the original design of CiviCRM as an easy add-in to an existing CMS, and feels contradictory in some ways to the open source spirit, but I think it's time for CiviCRM to stop trying to be easy at the cost of security. The security landscape has changed in the last couple of years and our assumptions need to be reconsidered.
So, do you have your CiviCRM installed on a CMS that is on a cheap shared infrastructure? Maybe it's out of date and no one can figure out how to update it without breaking something? Is security a topic that no one wants to talk about because you know it's going to end badly?
Here's my free advice:
- Consider splitting your CiviCRM from your public facing CMS. Here's my post discussing that option in detail.
- Find an expert in managed CiviCRM hosting. Yes, I'm in that list, but you might find a better fit in your own region/country. Managed hosting of a small CiviCRM install doesn't have to break the bank!
And good luck with your end of year fundraising!
Comments
Thanks for the blog! Splitting up the website from the CRM also resolves conflicts between the website dev timeline (which tends to be fast) and the CRM timeline (which tends to plod).
We do this. But splitting CiviCRM from the main web site STILL means wrapping CiviCRM inside a CRM with it's own vulnerabilities.
I think it's time to consider wrapping CiviCRM inside of a simple, stripped down Symfony wrapper that provides only the minimum that CiviCRM needs, such as a user account system, theme, and security system.
@robbrandt: we're working on it! (bringing back CiviCRM Standalone). A blog post announcing the initiative should be out by end of January 2022, but implementation will take a while, there are some non-trivial bits around user management. testing/tooling/c-i.
Well I am lucky to have Joomla that always have had security first approach. The new Joomla 4 is incredible stable, fast and secure so I am confident to use it for the future!
Cheers!
I submitted this post just before I read about the log4j vulnerability (https://securityintelligence.com/posts/apache-log4j-zero-day-vulnerabil…). That vulnerability has been identified as perhaps the most significant one of the past 10 years. Even if that's hyperbole, you can expect unexpected fall out in multiple ways, i.e. it's a good plan to be extra cautious in the next week. CiviCRM and it's CMS options generally don't use log4j (because it's a Java library), but there are always possibilities that the server you're hosted on is using it for other purposes (e.g. if you use Apache Solr for search with Drupal).
re: comments about joomla/standalone/etc. These comments very much miss the point. Neither of the vulnerabilities I noted are about Wordpress the core product. Any piece of code that is dealing with authentication and permission will be vulnerable at some point, in some way (that's an easy prediction!), and no amount of coding or posturing will change that. This post is meant to emphasize the importance of overall management and strategy when it comes to security.
At my org we are quite dependent on a couple of WP plugins that feed data into CiviCRM from Caldera Forms and Woocommerce. I'm thinking that to separate CiviCRM from the CMS would require rewriting those plugins to use the REST API for remote access. Is that accurate? It's not something we have the ability to pull off ourselves or the resources to hire out so it seems infeasible to consider this until there is community development of these critical integration pieces that supports it.
That is basically correct @robinhood. You might want to check out the Form Processor extension (https://docs.civicrm.org/formprocessor/en/latest/). Almost all of our customers do split their public website and CiviCRM for security reason, but it also helps to avoid configuration clashes and speed of updates. Whilst your public website has to be updated regularly as it is the biggest security risk, a CiviCRM installation behind a fire wall using CiviProxy is far less so. All of our customers use a number of extensions and customizations which makes testing an involved process where often all of the business processes have to be tested by users. This usually means updating is done once every year or every 2 years. Splitting is then extremely important for security reasons.