Title of the day: Software Architect of Awesomeness Hi, I’m Gordon Forsythe and I’m a software developer. I’ve been a professional programmer for around 20 years. In the various jobs I’ve had, I’ve worn many hats and been involved in many industries, including healthcare practice management & insurance, real estate, education and some things I’d prefer my family never hear about. I also run (with a little help from my friends) the azPHP developer group. Like any good developer, I feel like I never know enough and continue to learn new things. Yes, this paragraph was copied verbatim from my previous post on what’s happening behind the scenes at Pagely. I will try to continue that series soon. I started my career many years ago as most “web developers” did, as a HTML/Javascript code monkey. From there, I evolved by learning a few programming languages, settling primarily on PHP. I’ve worked at software agencies, small, and large companies, leaving a trail of hopefully better practices and code. More recently in my career, I’ve begun to work more with separating front & back end technologies for better maintainability and scaling, which is part of my focus here at Pagely. Getting the band back together Oddly enough, one of my earlier jobs was working with Joshua Eichorn, who is now Pagely’s CTO. We’re both relatively opinionated about the tools and code we use, but mostly agree on what needs to be done. It’s been great working with him again, and the Pagely family has been awesome as well. Unlike many companies I’ve been at, every person working here is a master for their field and extremely intelligent. What Am I Doing At Pagely? I started at Pagely with the primary goal of rebuilding the administrative infrastructure (internal and client-facing) from scratch. When I say administrative infrastructure, I’m not talking about the WordPress site deployment architecture, I’m talking about the user interfaces and data required to render said interfaces. These maintain and administrate our infrastructure and are used for our customers to administrate and maintain their hosted sites and features with us. To most of our customers, you know this simply as “Atomic”.
This is the beginning of a short series of articles on various technologies and design/architecture patterns we’re using to rebuild the administrative infrastructure at Pagely. We’ll get to the meat (or soy-based substitute for the vegans out there) of the article momentarily. First, I want to introduce myself since this is my first “official” article. Hi, I’m Gordon Forsythe and I’m a software developer. I’ve been a professional programmer for somewhere around 20 years. In the various jobs I’ve had, I’ve worn many hats and been involved in many industries including healthcare practice management & insurance, real estate, education and some things I’d prefer my family never hear about. I also run (with a little help from my friends) the azPHP developer group. Like any good developer, I feel like I never know enough and continue to learn new things. With those years of experience comes wisdom. One of the most important bits I can pass on is summarized by a quote passed on by a friend: “I think most programmers spend the first 5 years of their career mastering complexity, and the rest of their lives learning simplicity” – Buzz Andersen A good rephrasing of this (and possibly the inspiration for the above one) is: “Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.” – Alan Perlis It was this mindset, along with my “get shit done” work ethic which probably got my former co-worker from long ago and current CTO of Pagely, Joshua Eichorn, to ask me–multiple times–to come work with them…so I did. What Am I Doing At Pagely? I started at Pagely with the primary goal of rebuilding the administrative infrastructure (internal and client-facing) from scratch. When I say administrative infrastructure, I’m not talking about the WordPress site deployment architecture, I’m talking about the user interfaces and data required to render said interfaces. These maintain and administrate our infrastructure and are used for our customers to administrate and maintain their hosted sites and features with us. To most of our customers, you know this simply as “Atomic”. This brings us to today and the subject of this article. We are currently working on the underlying architecture of the new system and wish to share what we’re working on and troubles we run into. Here’s a list of the high-level bits that we’re going to be using for the new system and what will probably be the topics of the articles to come: 1. Microservices In order to have a maintainable infrastructure and allow for more rapid release cycles, we are going to implement a small service for each underlying “feature” of the platform. For example, there will be an API for authentication, one for billing, one for site deployment, one for account configuration, one for log analytics … you get the picture. Previously, most, if not all of these, would be housed in a single application. Each microservice contains its own set of tests, so running them only takes a fraction of the time it would normally be in a full-featured API. 2. Single-Page Application Previously, the interface of all of the administration tools used the standard old-school method of rendering everything on the server and spitting out an entire HTML page every time you click on something. Doing this is incredibly inefficient as every time this happens database or cache queries must be done to re-render the entire page; everything from login info, status notifications, to re-rendering all of the links in the interface based on the user’s role or security level. In a standard webpage, this is the norm, as it needs to be scannable by search engines so the content can be easily found by others. Since we’re talking about an application here (a set of applications, really) that requirement does not apply since you have to be logged in to even get to the interface. To put it simply, a single-page application is loaded once, then uses javascript to make tiny API calls to our aforementioned microservices in order to fetch or save information to or from the interface. Once you’re in, you should never really need to load a new page as long as you stay logged in. Changes of information in the interface will now only require one or two API calls, each of which only does a few operations and should therefore by pretty snappy. 3. Containers The actual deployment of the individual APIs and front ends will be handled using containers. Containers have been recently popularized by the Docker platform, but there are many methods for creating and handling containers. Containers, to summarize, are a way to consistently deploy a process without requiring an entire virtualized OS. For example, the previous development process for our new architecture would require me to spin up an entire virtual machine for every single microservice, databases and front end, each with their own CPU and memory requirements. Each VM would also have its own dedicated set of filesystems, duplicating quite a bit of data and slowing down my development box to a crawl. Utilizing containers, each service still runs in its own separate environment, but much of the underlying system is shared as long as they run on the same base “image.” Once a container is built and is running properly with the right code, it can be “published” to a container repository, where it is stored as a simple file. We can then deploy that container multiple times and each one will be exactly the same. The previous method of building up a new virtual machine or a new VPS each time we need to scale or update means each one would not necessarily be exactly the same, therefore creating inconsistency and, possibly, bugs. 4. Centralized Logging Oh, the logs! Where to find logs for the API? No, what about the web server logs? Perhaps a database query failed? Where do I find that? Was that request even logged? How the heck do I run stats on all these files? If that sounds familiar, you may want to look into a way to centralize your logging. Centralized logging is exactly what it sounds like–putting all the logs in one place. There are quite a few services (both commercial and self-hosted) out there which allow you to do this. Most use a collector to stream your logs to a central database. This allows you to easily filter logs or simply watch them stream by. Doing this, we can easily find and correlate issues between different microservices and/or features. We can also just ensure things are running as they should, without having to have ten “tail” terminals running. Many systems also allow you to split and send specific data to metrics databases so you can easily see application throughput, error rates, query times, etc. 5. Continuous Integration (CI) Our new code hooked into a continuous integration system making it easier to test it. Each time we push or merge to our code repo, our CI system will do a fresh checkout of the code. It then builds a pre-configured container for it and runs the unit and integration tests on all the things. If all tests pass and the code was on one of the main branches specified for certain environments, then that code will be packaged into a new container and deployed automatically. There are still many smaller pieces of the puzzle which are up in the air other than the ones mentioned here. We’ll collapse the waveform on those as we get to them. In order to test out this new architecture, we are adding a few new features to the existing stack and starting with those being the topic of the microservices and interfaces to build. That interface will turn into the full-featured internal admin UI once everything is built out. Eventually, we will have the new and old systems running in parallel until we deprecate the old one. Notice that I haven’t given any specifics on which products we are using. Yes, I could give some of them now, but you’ll have to wait for the detailed articles to come. See you next time!
This article covers our public notifications related to major security issues our clients and the WordPress community should know about. We are always focused on prevention and the mitigation of risk to our clients, and keeping you updated here is part of that process. List of Vulnerable Plugins During This Month Plugins Removed From the Repository WordPress security team decides to close a plugin when a security issue is found and the developer doesn’t release a patch in a timely manner. You can read more about this here. If you are using one or more of the above plugins we recommend deactivating them until the developer releases a patch for the mentioned vulnerability or consider a more reliable alternative. Relevant Vulnerabilities Ti-woocommerce-wishlist : Authenticated WP Options Change A critical vulnerability was found in this plugin that when exploited allows an attacker to: Change the site options Create malicious redirects Escalate privileges (login as an administrator) This issue was resolved in the free version 1.21.12 on October 16, however when checking the premium version we noticed it was still vulnerable and was finally resolved on October 28 after we reported it. More details here. WPBakery Page Builder : Authenticated Stored XSS WPbakery Page Builder former Visual Composer had a medium vulnerability in versions before 6.4.1 that was only exploitable by high privilege users. Nevertheless we recommend all its users to update to the latest version. Loginizer : Unauthenticated SQL Injection Loginizer had an unauthenticated SQL Injection in versions before 1.6.4 caused by a lack of filtering before executing a database query. An attacker just had to craft a request with a malicious username. More information here.
Pagely is thrilled to announce our partnership with Object Cache Pro. Utilizing state of the art compression technology, Object Cache Pro is now part of Pagely’s core offering, and available to all of our customers, platform wide. Offering major cost savings, access to some of the world’s best technology, and a dedicated DevOps team to personalize your setup, Pagely customers can look forward to continued scale and growth, with no hosting friction. A first of its kind partnership, Pagely is proud to help fund innovation in this WordPress space by investing part of our budget into working alongside the fantastic team at Object Cache Pro. We’ve already seen great gains with Object Cache Pro and our customers can look forward to more in the future! Why Object Cache Pro? Before Object Cache Pro, we faced two challenges with sites making use of an object cache – CPU overhead and network saturation. The underlying technologies in Object Cache Pro solved both of these problems for us, translating to less money spent on server hardware and fewer situations where the (quite generous) AWS network limits are reached. With Object Cache Pro’s state of the art technology utilizing the Zstandard compression library from Facebook, without a lot of CPU overhead, compression is now done at the extension level, talking to and from Redis. This means less hardware, lower costs, and a better experience for our customers. Aside from supporting an efficient compression algorithm (zstd), Object Cache Pro also uses the igbinary serializer which is a drop-in replacement for the standard serializer in PHP. This works about twice as fast at serializing and unserializing data. Additionally, the data footprint is smaller when using igbinary and that translates into less memory being used by the underlying Redis service. We also found an in-depth comparison on igbinary vs other serializers on Blobfolio that you may also enjoy reading if you’re into this kinda stuff: https://blobfolio.com/2017/03/benchmark-php7-serialization/ With a wide selection of Redis plugins available in the WordPress marketplace, Object Cache Pro was the obvious choice for us not only because of their forward-thinking tech but also because of the dependability we have come to expect and appreciate from their brilliant team. All of this aside, Object Cache Pro is unrivaled when it comes to bug fixing, an extent to which is a rarity across opensource software. There’s a saying in the opensource community that goes, “there’s a lot of eyes so all the bugs get fixed.” But, more what we see concentrated use of the software by lots of users leading to fewer bug fixes for fear of breaking one users’ site. That, and, no one owns the codebase, so less can get addressed in a timely manner. Similarly, we are continuously impressed by their coverage of testing, fully unit tested with 100% code coverage. Further, switching over to Object Cache Pro gives Pagely customers access to our commercial relationship with their team, which means any problems our customers see are fixed within a few days. You benefit from our relationship. Fewer bugs in the caching layer and full unit testing is a good thing, and that’s something we stand behind. So, What’s in it for the Pagely Customer? We are the first premium host to achieve this level of partnership with one of the best technology companies in WordPress. Through our relationship with Object Cache Pro, every single Pagely customer benefits from the work we’ve done to secure that. But real talk, what’s in it for you? Major cost savings. Even when it means less revenue for Pagely, we’re constantly looking out for cost savings for our customers. By decreasing our dependency on more hardware, you see the savings directly on your bill. Access to a premium partner. Since you’re at a premium hosting provider, you automatically get access to the partnerships we’ve developed. What’s more? You don’t pay an extra licensing fee. The best tech, baked into your Pagely account. We’re always on the hunt for the best and most innovative technology for you. With no effort on your part, we do the legwork of implementing this tech across our technology stack. All you do is benefit from it. Bigger performance wins possible with a little extra code work. WordPress has a feature called Transients. It’s a way to store the result of a complex query or a long-running remote API call temporarily in order to make subsequent lookups for that data return a lot faster without doing the same expensive operation again. Normally without any object cache, transients are stored in the WordPress database’s wp_options table. When using an object cache, it is stored in memory. Adding a few extra lines to your code allows you to tap into the power of this API for incredible performance gains. Having an efficient object cache utilizing fast compression and serialization only increases those gains. A dedicated DevOps team. While others might catch on and jump on the bandwagon of partnerships like this, Pagely still stands above the rest in meaningful ways that translate to real gains for you, the customer. Our DevOps staff becomes your dedicated, in-house team. Our engineers handle all the setup and optimization to make sure your usage of Redis is optimized specifically based on your exact circumstances and needs. Other hosts don’t do that! When you partner with Pagely for your WordPress hosting at scale, you know you have selected the most forward-looking host driven by advances in technology, cost savings for you, and tangible outcomes that help your business thrive. Object Cache Pro Helped FanSided Scale So let’s get to a real-life example here. One of the first Pagely customers we switched over to Object Cache Pro was FanSided. Here you can see a dramatic decrease in network utilization on the Amazon Aurora RDS instance after implementing Object Cache Pro along with custom Transients Caching, which dropped usage from 1 Gigabit per second to 400 Megabit per second; and yielded even lower usage after some more optimizations were made. FanSided comprises a massive network of over 300 active websites and needed a fast solution to maxing out servers and using way too much CPU. Pagely found that solution in Object Cache Pro and implemented it with no effort on FanSided’s part to completely eliminate those issues. Here you can see how memory is no longer being maxed out after the date we turned on Object Cache Pro for FanSided. The proof is in the data, and here you can see dramatic drops in CPU usage after Object Cache Pro was implemented, as well as servers being maxed-out-no-more after the switch. Dramatic drops in CPU usage after implementing Object Cache Pro for FanSided. Read the full FanSided + Object Cache Pro case study here, and take it from our CEO: “In the vacuum of 1 website, a small performance gain is useful. At our scale of hosting, processing hundreds of billions of requests per month across thousands of AWS EC2 instances, a small performance gain to each site means a real and quantifiable benefit to our customers and our bottom line. Now what if that performance gain was not so small, but major. We sought out and partnered with Object Cache Pro after seeing the dramatic results in terms of performance and resource usage when testing. We have thus deployed their Enterprise solution fleet wide and the results speak for themselves.” – Joshua Strebel, CEO of Pagely
Catch up on the conversation. This piece comes as a followup to our CEO Joshua Strebel’s recent piece on why you should never pay your WordPress host for pageviews. Managed WordPress hosting has exploded across the hosting industry since Pagely created it way back in 2006. Overall, the level of innovation that the mainstream has brought to WordPress is amazing. Unfortunately, this sometimes comes with negative side-effects. As investors demand higher profits, many of these managed WordPress hosts are looking for ways to gain a quick and easy boost to their margins. Like we mentioned in our definitive guide to PHP workers, there are a few different metrics that are often misinterpreted, whether intentionally or not. Today, we’re going to talk about pageviews and their role in the managed WordPress hosting world. What Counts as a Pageview? Many hosts cite pageviews as a billing metric with vague term descriptions, if any exist at all. Even with clarified definitions, pageviews tend to mutate on a host-by-host basis with a dizzying array of buzzwords. Although individual managed WordPress hosts vary on what they consider a “pageview”, most define it like this: pageviews are the number of unique IP addresses that access pages on your WordPress site per day, excluding known bots. (Yeah, I know. The term is more like “the number of unique request sources per day, based on predefined catch-all filters.” But I wasn’t the one that made this up, so bear with me here.) Pageviews as a Billing Metric Before we dig in any deeper into the details, let’s think about the definition that I mentioned. Considering that narrative, which of these sites would be more expensive to host? A directory website that houses billions of pages, showing 1,000 entries at a time. A personal blog who’s majority of traffic is to single posts. A documentation site where visitors typically access multiple pages per day. A simple informational website for a local restaurant. An online shop that sells small-batch artisanal snake oil. An API that uses headless WordPress to dynamically fetch content. If you guessed that they represent the same metrics in the eyes of pageview-based billing, your logic prevails! Assuming that they all experience the same number of unique visitors, they’re all treated the same way, regardless of how resource-intensive the site is or how many pages each visitor accesses. Of course, it would be silly to treat all of these sites the same way. Some pages might have large amounts of fully dynamic content, while others might be eternally served from cache. Using an umbrella term like pageviews as a billing metric causes several different issues, based on the site being hosted. Setting Realistic Expectations The first issue that pageview-based billing causes is an unrealistic expectation for low-performance, unoptimized sites. If you’re not familiar with how WordPress sites perform on the server side, you might think that these limits matter exclusively and use them to determine what capabilities you need from a hosting provider. If you’re evaluating your hosting options purely based on a pageview limit, you’re ignoring critical factors that can dramatically impact your WordPress site. Performance-Based Punishment What if you’ve put hard work into optimizing your site? Well, now you’re wasting money on a billing metric that doesn’t matter. If your site is highly cacheable, you’re feeling the impacts even further. When serving content from cache, it’s practically free from a hosting perspective. You’re being nickel-and-dimed for something that is entirely outside of your control. Knowledge is Power As you scale, knowing what you’re paying for can quickly become a critical part of maintaining a healthy, cost-effective site. Coupled with the fact that the same people who are charging for pageviews tend to hide their underlying infrastructure behind the curtains, there’s no way to verify or manipulate what’s being counted. While many claim that they exclude the known IP addresses and user agents of known bots from counting towards your monthly pageview bill, what’s their motivation for even bothering? After all, more pageviews mean more money in their pockets. Pageviews Are Still Helpful Many of our prospective customers ask, “How many pageviews can ‘x’ plan handle?” Like we mentioned earlier, the impact of each pageview dramatically varies based on the type of content viewed and how your site was developed. Every WordPress site is different. It would be impossible to accurately estimate the ideal hosting environment without a complete understanding of what your site’s usage looks like. Although pageviews are a faulty metric as far as billing is concerned, they can still be useful as part of a larger dataset. Whether you’re scaling, optimizing for better performance, or shopping for a new hosting provider, pageview data plays a role in getting a full picture of your site. For example, if you were running benchmarks to determine your server’s capacity, pageview data could be used to identify what a typical day looks like. Let’s say your site looks something like this: 10% of traffic is on the home page. 30% of traffic is to various landing pages. 30% of traffic is to different blog posts. 20% of traffic is to your product’s pricing page. 10% of traffic is on account-related pages. Using that traffic data, you could then estimate what types of content have the most significant impact on server resources. You may find that some pages underperform and could use some optimization, while other highly-cacheable content, like blog posts or landing pages, remain essentially free. If 90% of your traffic goes to fully-cached content, increases in traffic have a trivial impact on your bottom line, if any. Closing Remarks Operating a WordPress site at scale is all about a delicate balance of performance and cost. At Pagely, we partner with our clients to help them achieve those goals. While shopping for a new hosting provider, be on the lookout for hosts that impose false barriers, such as PHP worker limits and pageview counts. Those vague limitations are a red flag that they’re going to try to upsell you later. (These limitations are also a sign that they’re trying to sell you on shared hosting resources too, but that’s a topic for another discussion entirely.) We hope that you’ve learned more about the impact of pageviews (or lack thereof) and why it’s not an appropriate billing metric. Do you have any experiences with pageview-based billing that you’d like to share? Is there something we missed? Let us know in the comments below.
This monthly report is provided for the WordPress community at large from Pagely’s head of security, Robert Rowley. Rowley and the entire security team keep their finger on the pulse of any potential vulnerabilities that might affect our customers, as well as any WordPress user. We sincerely hope these efforts help any and all that could use information from the experts on monthly security issues. We commend the researches and developers that help to identify and patch these issues in a timely fashion. WordPress Core No notable WordPress core security releases. Plugin/Theme Vulnerabilities of Note Security & Malware scan by CleanTalk https://wpvulndb.com/vulnerabilities/10292 This vulnerability within CleanTalk allows an authenticated user, such as an editor or subscriber, to make unauthorized Ajax calls which could lead to file deletion or downloads and also potentially function calls. Adning Advertising https://wpvulndb.com/vulnerabilities/10293 The Adning Advertising plugin has a vulnerability in versions lower than 1.5.6 which allows unauthenticated requests to upload or delete files, leading to an RCE attack, which can then lead to full site takeover. Wise Chat https://wpvulndb.com/vulnerabilities/10299 Wise Chat versions lower than 2.8.4 are susceptible to a CSV injection via a command sent in chat messages by an unauthenticated user that is included in an exported CSV file, which then could potentially lead to an RCE attack. Email Verification for WooCommerce https://wpvulndb.com/vulnerabilities/10318 The Email Verification for Woocommerce plugin prior to version 1.8.2 is affected by a loose comparison issue. This could potentially lead to any user (authenticated or non-authenticated), to log into the WordPress site. SRS Simple Hits Counter https://wpvulndb.com/vulnerabilities/10316 The SRS Simple Hits counter plugin is currently vulnerable to an unauthenticated blind SQL injection vulnerability. The responsible reporting parties at Tenable ( https://www.tenable.com/security/research/tra-2020-42 ) are working with the developer to write a more comprehensive patch to address this vulnerability, and will not release more details on the attack until they know a patch has been released. Site owners using SRS Simple Hits Counter plugin on their sites should keep an eye out daily for the patch to be released. Payment Form For Paypal Pro https://wpvulndb.com/vulnerabilities/10287 The Payment Form for Paypal Pro plugin versions before 1.1.65 are vulnerable to an unauthenticated SQL injection attack. The attack is a trivial single request which can expose the contents of your database (which includes user passwords and potentially other secrets) to the attack. This is a high risk vulnerability and site owners should patch immediately. WooCommerce Subscriptions https://wpvulndb.com/vulnerabilities/10330 The WooCommerce Subscription plugin is vulnerable to an unauthenticated stored cross site scripting (XSS) attack in the subscription billing process. Attackers can submit their XSS attack payload to during the billing step in the signup process, and later that payload will be executed on the browser of the administrator/user who reviews the attacker’s account. Site owners should update WooCommerce Subscriptions plugin to version 2.6.3 and not check any new user account information until that update is performed. TC Custom JavaScript https://wpvulndb.com/vulnerabilities/10325 The TC Custom Javascript plugin is vulnerable to an unauthenticated stored cross site scripting attack. Sites running versions before 1.2.2 should update immediately, attackers can add their own javascript or HTML to the footer of all pages loaded by WordPress with a few basic requests. This vulnerability is likely to be targeted by SEO spam bots. KingComposer https://wpvulndb.com/vulnerabilities/10297 The KingComposer plugin is vulnerable to a reflected cross site scripting vulnerability in versions before 2.9.5 This means the attacker’s malicious HTML/javascript will only be available to the browser making this request. This still poses a high risk if an attacker can trick an already logged in user to click on a malicious link/form to the website, potentially exposing secrets viewable by the user giving them to the attacker. JobSearch https://wpvulndb.com/vulnerabilities/10328 The JobSearch plugin versions before 1.5.6 are vulnerable to a reflected cross site scripting vulnerability. Much like the KingComposer vulnerability above it is a high risk if logged in users to be targeted. The proof of concept for this vulnerability will be released on August 6th, 2020, site owners should patch before this date. See previous months’ WordPress security updates from May and June.
The benefits of this WordPress security guide are two fold: Learn exactly what you need to know about WordPress security in 2020. Understanding WordPress security helps you adopt a security-oriented mindset that will help you prevent and mitigate risks as you make day-to-day decisions. Get actionable, step-by-step instructions for securing your WordPress site. The steps you need to take aren’t particularly time-consuming, don’t require advanced technical knowledge, and the linked guides are vetted for clarity and completeness. Of course, it’s impossible to cover every possible vulnerability and scenario. That’s why we also include the overarching “principles of WordPress security.” If you can follow these broad principles many of the minute details that are difficult to address in this type of post will take care of themselves. Why is WordPress security critical? It’s important you understand how big an issue WordPress security is so you give it the time and attention it deserves. Here are some sobering statistics: Google blacklists 10k sites a day for malware and another 50k for phishing each week. A blacklist from Google kills that source of traffic which can be highly disruptive to a business’s revenue. Fixing and removing a blacklist can be a hassle, particularly if your server was used to send SPAM emails. A blacklist from email service providers harms your deliverability rate which undermines the effectiveness of your email marketing. In 2018, 90% of CMS hacks were WordPress. Granted, WordPress is the world’s most popular CMS with 34% of the web powered by WordPress, but this is still a disproportionate amount of hacks. For a variety of reasons, WordPress sites are targeted and exploited more than any other CMS. 60% of attacks target small businesses. You may think that hackers won’t bother with your site because you’re a small fish but “security through obscurity” does not exist on the web. No one is too small to be a victim of an attack. WordFence reports that there are over 97,978 attacks happening per minute. This is not a small, isolated problem. Large swaths of WordPress sites are being probed for weaknesses at any given time. Will you be ready if your site is targeted? While these stats paint an intimidating picture of what you’re up against, it’s important you confront the realities of managing a WordPress site in 2020. If your business relies on WordPress, security is not something you can afford to ignore. If you haven’t taken steps to secure your site, you’re vulnerable to attack. It could be only a matter of time until your site becomes compromised. This is one area where “an ounce of prevention is worth a pound of cure.” The principles of WordPress security Securing WordPress is more than checking off a list of boxes, it requires you to adopt a security-oriented mindset that guides your decision making. These principles will help you prevent mistakes as you make day-to-day decisions like adding new WordPress users, plugins, and themes: Vulnerabilities are often introduced by WordPress users. Vanilla WordPress that is kept up to date and uses strong passwords is relatively secure. It’s often the decisions made by WordPress users that create weaknesses that hackers exploit. This is why articles like this one are so important. It’s up to you to be educated on, and consistently follow, the WordPress security best practices outlined here. Minimize plugins and themes. New WordPress users are often overjoyed by the extensive ecosystem of plugins and themes available for WordPress. This can lead to indiscriminate installation of plugins. But, each new plugin or theme adds code to your site that, potentially, adds new vulnerabilities. By minimizing the plugins and themes installed, you also minimize the amount of code your site uses, and, by extension, the number of potential security vulnerabilities. In general, if you can solve a problem without installing a plugin, that’s the best option. Install updates as soon as possible. Updates to the WordPress core and updates to plugins and themes often contain critical security updates. They should be installed as quickly as possible. If you have a good back up strategy in place, you can roll back to a previous version in the event the update causes issues. Follow the principle of least privilege. This is a core principle of cybersecurity in general and is not unique to WordPress. This is a fancy way of saying, “don’t give a user more privileges than they need because those extra privileges give hackers more power and access than they’d otherwise have if they compromise that account.” Attacks can still happen. You can try as hard as you can to cover all the bases and still fall victim to an attack. This is why regular, automated backups are critical. Do not ignore this advice. A hacked site can be disruptive but can generally be fixed with minimal cost and disruption, a hacked site without a backup to roll back to can be severely disruptive. You are never finished with security. Having a 100% secure WordPress site is an impossible task. You can’t accomplish complete risk elimination, so aim instead for ongoing risk reduction. This “risk reduction” mindset prompts you to continue taking steps to improve your security as part of an ongoing, never-ending initiative. The most common WordPress attack vectors Understanding the most common methods hackers use to exploit WordPress will help you understand how to address them and why the steps recommended later in this article are necessary: Brute Force Attack A cyber criminal uses trial and error to identify a password or pin. They use combinations of common usernames and passwords until they find the right one. It’s the equivalent of trying every key on a key ring to find the one that works. This is all done using a computer script so they can run thousands of combinations with very little effort. Given enough time, any account is hackable but strong passwords thwart this kind of attack. SQL Injection Malicious SQL code is injected into a database to gain access to database information that was never intended to be displayed. Depending on the hackers goals, this can lead to your database being deleted, customer information being stolen, or sensitive company information being accessed. Malware A virus or spyware is inserted using an expired theme or plugin. The attacker can gain access to your data, insert pages into your site for black hat SEO, and perform a number of other nefarious activities using your site. Cross-site scripting Javascript code is inserted which then collects data commonly used to exploit WordPress plugins. This can be used to redirect your site visitors to malicious content. also known as an “XSS attack.” DDoS Attack A Distributed Denial of Service (DDoS) attack floods a website with traffic which overwhelms server resources causing it to fail. Multiple machines send frequent requests to the server using malware installed on those machines for that purpose. The distributed nature of the attack can make it difficult to identify and block the sources of the traffic. Now that you understand how hackers will attempt to breach your site security, let’s look at how we can block and prevent these attacks… Steps to secure your WordPress site In spite of the many ways your site can be compromised, it is possible to mitigate these risks and prevent many attacks. Here’s a list of recommended steps to protect your WordPress site from security attacks: 1. Force Strong Passwords “81% of attacks are based on insecure or stolen passwords” “It only takes about 10 minutes to crack a lowercase password that is 6 characters long.” These two facts taken together make the case that you must use strong passwords for all WordPress users. Strong passwords are long and use a combination of upper and lower case letters, numbers, and symbols. Longer is better but 20-characters is probably plenty. Strong passwords are difficult to memorize, especially if you’re using unique passwords for each site (you should be!). This means a password manager, such as LastPass or Dashlane, is a critical tool. These apps make creating strong passwords easy, store them in a central location, and make logging into your websites easy by autofilling your passwords. Here’s how to make sure all your WordPress users are using strong passwords. 2. Turn on automatic WordPress Core updates One of the advantages of using a popular CMS like WordPress is that there are many people with a vested interest in keeping it secure. Thousands of people are contributing to WordPress security by reporting vulnerabilities to the WordPress team. This widespread collaboration means most holes are patched relatively quickly. But, if the updates that contain those fixes are not applied, you leave your site vulnerable to attack. The best way to ensure your WordPress core updates happen quickly is to turn on automatic updates. This way your WordPress site will be kept up-to-date without you having to do anything. Here’s how to turn on automatic core updates by modifying your config.php file. 3. Stay on top of plugin and theme updates You absolutely must keep your plugins and themes up-to-date. The importance of this cannot be overstated. You’ll also want to be careful to use plugins and themes that are updated often. If you’re using a plugin or theme that has not received an update in months, it’s a good idea to check in with the developer or find a more frequently updated plugin that accomplishes the same goal. When you search for a plugin in the WordPress plugin database, this information is provided in the sidebar: 4. Use Two-Factor Authentication (2FA) Two-factor authentication adds a layer of protection to your WordPress site by making it nearly impossible for a hacker to log in to your site — even if they know your username and password. You should set up 2FA for all WordPress users. 2FA can be set up quickly with simple, free plugins. Here’s a list of available 2FA plugin solutions for WordPress. 5. Brute Force protection Even with 2FA and strong passwords, it is good to setup brute force protection to help with overall performance on the server by reducing the amount of work PHP has to do. Here’s how to protect your site from brute force attacks. 6. Create automated, scheduled Backups In the event of an issue, there should always be recent database and file backups available. You should also create a backup before making any major changes to your site, such as installing plugin and theme updates. Many of the popular backup solutions take care of this for you. Here’s a list of backup solutions for your WordPress site 7. Change your login pages The default login pages for all WordPress sites are sitename.com/wp-login.php and sitename.com/wp-admin.php. Using these default login page URLs makes it easy for hackers to begin a brute force attack by trying combinations of usernames and passwords. By using a login URL that is difficult to guess, it makes it more difficult for hackers to begin the brute force attack because they don’t know where the login form lives. Here’s how to change your login page URLs. 8. Use SSL Secure Sockets Layer (SSL) encrypts all data sent from your website to the visitors browser obscuring potentially sensitive data. Using SSL has many benefits in addition to security. Google may rank your site higher in the search results and many browsers indicate whether a site is secured by SSL which can reassure them your site is trustworthy. Here’s a tutorial on setting up SSL for your WordPress site 9. Don’t use the default database prefix Using the default “wp_” database prefix makes it easier for a hacker to insert code into your database (SQL injection). Here’s how to change the default database prefix for a new site and an existing site. 10. Check your folder and file permissions File permissions define what actions can be applied to the files on your server. You should never set any WordPress file or directory to 777 permissions. Instead, make sure your permission scheme is as follows: Folders – 755 Files – 644 Here’s a guide to checking and fixing the permissions of your WordPress files and folders. 11. Disable pingbacks WordPress pingbacks are enabled by default. But for most sites, they offer little benefit. But, they can be used to turn your WordPress site into an unwilling participant in a DDoS botnet. To turn off pingbacks, you can go to “Settings –> Discussion” and uncheck the “Attempt to notify any blogs linked to from the article” box. It’s also a good idea to uncheck the “Allow link notifications from other blogs (pingbacks and trackbacks) on new articles” box: 12. Hide your WordPress version number One of the ways attackers gain access to a site is by exploiting known vulnerabilities in outdated versions of WordPress. Hackers can scan your site and easily find out what version of WordPress you’re using. If that version has a known vulnerability then the hacker has a good idea of how to proceed. The best way to prevent this is to keep WordPress up to date. However, you can also prevent a hacker from finding out what version of WordPress you’re running. Here’s how to hide your WordPress version number. 13. Don’t use the admin username Hackers can safely assume that a WordPress site is using the default “admin” username and that username will give them admin privileges so all they need to do is figure out the password. This gives them a direct path to gaining admin access to your site with a good probability of success. Eliminating the admin username makes it significantly more difficult to attack your site this way. If you’re already using the admin username, that’s okay, you can change it now. Here’s how to change the admin username. 14. Use a secure Managed WordPress Host A host that supports all the major CMSs will have difficulty staying on top of WordPress security. By specializing in the WordPress CMS alone, a WordPress hosting provider can devote the resources necessary to prevent many attacks. A reputable Managed WordPress Host will have a security team dedicated to shielding your site from threats. They’ll handle many of the concerns raised above like taking care of WordPress updates, creating backups, and more. Here at Pagely we have a comprehensive suite of security features called PressArmor that handles both WordPress application security and server security. Security questions to ask a potential managed WordPress host: Is your hosting environment chrooted? If your host has multiple domains on the same server, check with them to ensure they use chroot to isolate each WordPress app. If one app is hacked, this would help prevent access to other apps on the server. Is SSL included and easy to set up? A good WordPress hosting provider will provide SSL free of charge using a service such as Let’s Encrypt. Do you actively monitor my site specifically for WordPress vulnerabilities? If you detect a vulnerability on my site, how will you inform me? A good WordPress host will stay on top of the latest threats to WordPress sites and constantly scan your site for those threats. If they find a vulnerability, they will work with you to address it. Are you using a web application firewall (WAF) to protect my site? A WAF block malicious traffic before it reaches your site and can help prevent XSS attacks and SQL injections. Here’s a list of important considerations for choosing a Managed WordPress Host. Conclusion WordPress security cannot be taken lightly and you must take steps to secure your site. Using a Managed WordPress Hosting Provider like Pagely is one of the best ways to improve your security because you will have an experienced team dedicated to protecting you. Whether you choose to handle WordPress security yourself or leverage a host that specializes in WordPress, it’s important to treat WordPress security as an ongoing effort. You are never done with security but if you’ve taken the above steps you’ve protected yourself from many of the most common threats.
Since this is the internet – and the rules of the internet clearly state everyone gets an opinion, I’d like to share one of mine around website hosting billing plans. Quick backstory: 10+ years ago when we launched Pagely we did so with a simple line on our pricing page denoting a rough estimate of the expected capabilities of that plan ie: Plan – 1 was suitable for ~1 million pageviews. Along came the next several providers who did something similar with one important difference. They actually attempted to measure and cap pageviews per hosting plan, bracketing their plans by this new billing metric. In my opinion Pageviews used as a billing item is a predatory and anti-consumer practice and you should be very wary of working with any company that applies this #successtax to your monthly bill. Definition of anti-consumer : not favorable to consumers: improperly favoring the interests of businesses over the interests of consumers Hi, I’m Joshua Strebel, Co-founder and CEO of Pagely – A leading Managed WordPress hosting company – Thank you for attending my TED Talk. What are you buying when you are buying “hosting”? To host a WordPress site you need a few key components. A server (a computer) connected to the internet with software installed to process requests and responses for your application. Storage / Disk space attached to that webserver to save your files to. Data Transfer / Bandwidth. This is the pipe the information flows through. That’s basically it. Hosting providers typically lease/sell you packaged fragments of these resources for a monthly fee. Plan A, Plan B, Plan C. etc. Of course there are other items that may be line-itemed such as included support levels, CDN GB’s per month, managed services, etc. Plan A has X amount of consumables for Z price. It’s all fairly straightforward as most consumers understand what a Gigabyte of Disk space is and can at least grasp that more CPU/RAM offered should equate to more potential performance. “Pageviews” does not fit this model well – as the definition of a pageview is amorphous and subject to exploitation. Oh, and spoiler alert, PHP workers is not a valid billing metric for WordPress hosts either. What does an automobile lease have to do with hosting plans? Pageview limits on hosting plans are akin to annual mileage limits on auto leases. It’s a cap on the use of an asset you already purchased. In an automobile lease context a mileage cap at least has some merit as being a form of controlling the depreciation of the vehicle – you are essentially financing the deprecation of the automobile asset with a lease – and the lease company expects to sell that car (New retail value – Depreciation) when you return it. If the depreciation is too high, they lose money on that transaction as they have to sell it for less than they calculated. Your hosting plan is not a depreciating asset though – the hosting company is going to sell the same resources to the next customer when you are done for the same or likely higher fee. Therefore in my humble opinion: Pageviews are just an arbitrary anti-consumer fee – a penalty tax for using the service you already paid for. A Pageview is (depending on who you ask) a wrapper around these items: A measurable amount of Data Transfer in and out A measurable amount of CPU resources to process the request and render the response A measurable amount of Disk and Database activity Are you not already paying for these items as part of your hosting plan? Hint: Yes you are. But wait, there’s more – and my colleague will dig into these more in a future post. This pageview billing model is so poorly defined by the hosts that use it – it is ripe for abuse. It’s a scheme to generate revenue for the hosting company and unfairly penalizes the consumer. Hint: You already “paid” for the sum of the parts of a “pageview”. No two pages are the same. A cached page even with a few images can be served a million times a month with ease, and yet a badly coded membership-site page may tax the hardware it runs on each time it loads. They have very different cost profiles to the host – yet both are treated equally under this model. If you invested the time to optimize your site, get it caching well and then blow it up with viral traffic.. That is a GOOD day for you and costs your host pennies of the monthly fee you are already paying them – yet when you get the overage bill for exceeding your pageview cap at the end of the month, are you going to enjoy that tax on your success? If you want to keep paying twice for the same resources you are welcome to. I simply do not think that is fair. Our friends down in Austin have made millions on charging their customers overage fees for exceeding their monthly pageview cap – even to the point having to publicly respond to criticism – only to keep the practice in place. Reminds me of airline baggage fees and fuel surcharges. and An “online payment convenience fee” when they only accept payments online. and JetPack being “free”. Happy WordPress’ing – Joshua Strebel
