How To Secure a Coupled Content Management System

p>One of the most important parts of our web content management system (WCMS) methodology is our focus on security. Sadly, security is often an afterthought for many enterprises as they decide what CMS platform to install for their corporate web presence.

Given all of the recent news stories about targeted hacking, malware injections, and other security breaches floating around, it’s more important now than ever to discuss security as a major factor in a CMS rollout.

To help facilitate this conversation with our potential customers, we’ve developed two graphical models to help explain how CMS platforms are architected and how they can be secured. Our models focus on two scenarios.

First, we focus on integrated CMS platforms such as WordPress, Drupal, and similar monolithic platforms and how they can best be secured. Our second model details the difference between integrated platforms and headless or decoupled solutions.

For the purposes of this post, we’ll focus on the first model, which when completed looks like this:

At first glance, this is definitely a complicated graphical model. So to make things easier, we will explain it step by step.

First, let’s start with what an integrated CMS means. In the following graphic, we can see that the CMS platform and the front-end display of the website is integrated into one unit of software. This is the architecture of today’s most popular CMS platforms, including WordPress, Drupal, Joomla, and most enterprise platforms as well.

In a nutshell, this architecture means that the front-end display of the website and the administrative portal are all based on essentially the exact same code base. This connection means that what affects one end of the solution affects the other as well. You could also consider this to be a “coupled” architecture—it is near impossible to separate these two parts of the architecture—and if you succeeded, you would defeat the point of even using the platform in the first place.

The next graphic begins to lay down the foundation of how these systems work. CMS platforms require underlying technology to function. This includes the following core components:

• Database: A database such as MySQL, MongoDB, or SQL Server is necessary to store the content, configuration settings, and most of the core data required by your CMS. A database is a separate piece of software running on a server. Much like utilizing a local piece of software on your computer such as Microsoft Access, these database systems are complicated pieces of software without which, a CMS would not be possible.
• Scripting: This is the core programming language on which your website runs. Most open-source CMS platforms rely on PHP. Microsoft-based platforms utilize .NET. And you have a variety of other options out there as well.
• Web Server: The web server is a piece of software that lives on your actual server box. Its job is to make a connection between the database, the scripting language, and the end user. Web servers handle the incoming requests from the user or client. They then put together all the moving parts to handle the request and relay the results (HTML code) to the user.
• Server: The actual “server” is a computer, either physical or virtualized, that runs an operating system. In this way, a server isn’t dissimilar to the Mac or PC that you use every day. Popular servers today run Linux, which is based on the Unix platform, or Windows. There are other players out there as well but their popularity is waning.

All of these technologies together create what technologists call your “tech stack.” Without these working in conjunction, your website will not function. As you can tell in the following model, these pieces must work together to enable your CMS to work. They communicate with each other and must be configured properly to enable your ecosystem to function.

Now that you have a CMS and understand what is going on behind the scenes, it’s time to dig into the users who are visiting your site.

The next image begins to introduce the concept of website users, who they are and what they are looking to function. As you can tell, an integrated CMS will accept users on both the front end and back end. However, this is good and bad.

Our model represents three types of users. First, you have your normal web visitors, denoted by happy blue faces. Secondly, you have administrators, those who work to control the website presence. They are represented here in green. Finally, you have your malicious actors, seen here as creepy purple skulls.

Notice how all three of these users are accessing your website on both the front and back ends. And also notice how malicious characters are accessing the site along with legitimate users and administrators. This cross-contamination is a major cause of concern within integrated systems. A nefarious character can access your website via the front end and, if they gain access, have an opening to take further steps to attack back-end data.

Also notice the group of malicious characters on the bottom of the graphic. This introduces the idea of high-traffic attacks (also known as denial of service attacks). An attacker could send thousands of fake and real sessions to your website and take down everything from your front-end user experience to the back-end administrative panel all with this simple attack!

As if that wasn’t scary enough, take a look at the next image. If a malicious actor gains access to your front-end software or your administrative panel, they can work to inject themselves into the depths of your server environment!

Here is a possible scenario. Let’s say you run an e-commerce shop utilizing WordPress and WooCommerce, a popular plugin that handles e-commerce transactions on WordPress. If someone were to gain access to your site via an injection of malicious code, they could either delete an entire database of users or customers, or worse, gain access to the data and steal it. Likewise, perhaps they could install software on your server to send spam emails posing as you. Or perhaps they can inject other types of malware. The possibilities are scary (and endless).

Finally, this is a point that many website owners overlook or don’t even know is possible. In our next image, we are pointing out another vulnerability. If you don’t properly lock down your server, you run a risk that the individual software components that power your site could also be attacked. This means the parts of your “tech stack,” such as your server, database, or web server, could be attacked individually without even compromising your CMS.

These scenarios are all extremely troubling. Thankfully, there are steps you can take to secure your CMS, and reduce the possibilities of attack.

First, we believe the best security is floating under the radar. Many attacks are executed via automated systems. The best way to avoid those attacks is to not give them the food they need to eat. If you have the ability to consider custom CMS solutions, they will always provide you with the absolute best, most secure environment, especially when considering automated attacks.

If that is not a possibility or not your preference, you can secure integrated systems. And that is what the next part of our model is all about.

In the below image, we start by taking steps to hide what our CMS is. As we said, being under the radar has its advantages. The first thing you can do is begin to hide what your platform is so attackers have a more difficult time determining the platform. One easy way to do this is to simply hide the administrative portal! So many WordPress sites expose their /wp-admin location, when hiding it isn’t the most difficult task.

Secondly, we are introducing an idea here of a firewall. This can be either hardware- or software-based. But a firewall between your CMS and your visitors is a cheap and easy step you can take quickly to ensure a higher level of security. The most popular provider that we recommend for this service is CloudFlare.

The next step is to also firewall your server and the individual components. It amazes me how often this is overlooked! This simply means avoiding leaving any open routes of exposure. MySQL, for example, is controlled via ports. Your firewall should always block MySQL ports from the outside world. In the vast majority of cases, it should never be open to outsiders. The same goes for your server in general—lock down as many services as you can. Ideally the only ports open should be for file transit (SSH or FTP, if you must), web traffic, and that is it!

Finally, with those steps taken, it is time to allow visitors to access the site. As represented in the following model, we can see our changes taking effect. Administrators can utilize the administrative portal, as they know where it lives and how to access it. Legitimate visitors are able to access the site through the software firewall. And as you can tell, DDOS attacks are now thwarted thanks to the CloudFlare firewall we have installed.

However, notice that malicious characters can still access your site. This is something that will always be difficult to lock down completely. However, we have made it harder for them to access the admin panel, harder to determine your platform, and because your components are protected, they are now unable to attack them individually. The ability to access them either using the CMS as a conduit or by attacking components directly is now significantly mitigated.

In looking at the differences from the first part of our model versus the second, you can see how we have secured your installation. We’ve worked to conceal, worked to separate powers and lock down components, and worked to avoid mass attacks with simple, effective, and quick changes to your infrastructure.

Why This Matters

If you are like the vast majority of website owners and operators, you’ve had no idea of the specifics behind how your website and CMS work. The purpose of these models is to give you an understanding of how a CMS looks when taken off the shelf and how it should look with some modifications to ensure a safe and secure installation.

So what are your next steps? You can begin by analyzing and comparing your website to the models. What protections are you missing? What can you do to prepare for the various scenarios we have presented? Do you have the technical know-how to prepare? Do you need help?

Remember, website security matters. A hacked website with stolen data could destroy a company. A defaced website could ruin your reputation. Are you prepared to accept the consequences of not securing your website, for both your company and career?